| Thread Previous • Date Previous • Date Next • Thread Next |
Le 01/04/2011 17:08, Wayne Stambaugh a écrit :
On 4/1/2011 1:42 AM, jean-pierre charras wrote:Le 31/03/2011 21:38, Wayne Stambaugh a écrit :On 3/30/2011 3:57 PM, jean-pierre charras wrote:Le 30/03/2011 19:49, Dick Hollenbeck a écrit :Seems Window specific (I did not see any problem under Linux Ubuntu 10.1). Tested with wxMSW 2.8.11 and 2.8.12 But with wxWidgets 2.9.1, no problem. Unfortunately wxWidgets 2.9.1 creates other issues.Jean-Pierre, What are problems with 2.9.1, and are they MS Windows specific? On Windows, if we do the full CMakeList.txt file build I have been advocating, this would entail using External Project to build wxWidgets too, we can apply patches to wxWidgets before building it. DickIn fact, there are very few and very minor issues, but one. The annoying one is related to floating point separator. When the floating point separator is a comma instead of a point, an annoying behavior happens. Gerbview displays always floating numbers (coordinates in status bar for instance) using a point. Pcbnew seems OK. The most annoying issue was seen with Eeschema. When starting Eeschema, the schematic editor displays floating number using a comma (this is OK) But depending on what dialog was opened (or after opening Libedit), sometimes schematic editor displays floating number using a point, after closing the dialog. This behavior depend on Eeschema version. For instance, previously, when opening and closing Libedit (nothing else is needed), eeschema revert to a point, but for now this behavior does not happen. And for users, this behavior is very inconsistent. And if your are entering (in a dialog) coordinates with the bad separator (that changes sometimes), floating numbers in the dialog are not correctly converted. (I must say I did not have a look to this issue, that should not occur, because inside Kicad, users should use a comma or a point as separator, whatever the current locale uses) I did not noticed this issue with wxGTK. I'll try to build Gerbview using latest svn wxWidget version (2.9.2) ASAP.JP, Your fix doesn't isn't quite what I expecting. I thought you found a solution with the blitting or the scroll bar position to solve the problem. Removing the zoom factors that result in non integer scaling factors will likely generate some complaints. Your fix als has the unfortunate side effect of calculating a best zoom value that causes the page to be truncated if the window size is not an even ratio of the drawing size. I'm sure someone will file a bug report against this. WayneI was thinking this ugly workaround was working. But you are right, there are many zoom values that do not work (I did not noticed these values). I'll work on it these newt days. If you find a better fix before I find a working workaround, please commit it.It may be worthwhile looking at the changes in wxMSW blit and scrolling code from 2.8 to 2.9 to see if we can figure out what the wxWidgets folks changed to fix the problem. Did the previous behavior cause items to be drawn in the incorrect position? I know that the screen center point moved a few pixels but other then the visual annoyance, was there a technical reason to make this change? If there is no technical reason for this change, maybe you should undo the changes until we can figure out why this offset only occurs at non-integer zoom scaling settings. Interestingly, you made no changes to PCBNew even though it too has zoom settings that result in non-integer scaling factors. It looks like PCBNew has this problem as well but it only seems to be off a pixel or two which make it barely noticeable. Of course this could just be my old eyes playing tricks on me. Is there a divide by a truncated integer somewhere in our math that's causing this problem? I won't be able to take a look at it unit sometime next week. Wayne
I tested 20 values from 0.1 to 2.0 (by step of 0.1). (No visible artefacts with zooms > 2 ) Only some zoom values create problems: zoom 0.1 and 0.5 works fine. zoom 0.7 has a noticable offset. Z zoom value = 0.3 creates a very large offset (10% to 20% of screen size) and a value = 0.6 creates a smaller offset When the screen is scrolled, Display is fully broken at 0.3 or 0.6. (When loading the component "C" in libedit, the "best zoom" is 0.6 on a1200x1000 monitor) For zoom values = 1 to 2, some values give a small offset. Due to smaller internal units, Pcbnew does not uses zoom values < 2 to 3 best the best zoom is used. And the values < 2 are 1.5, 1 and 0.5 that do not give offset! So I did not modified Pcbnew. But because wxWidgets 2.9.1 works fine, (There are very minor issues, but there are also minor issues in 2.8.11 and 2.8.12), I believe the best solution it to switch to 2.9.1 (at least under Windows) because there is no reason to use 2.8. -- Jean-Pierre CHARRAS KiCad Developers team. KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
| Thread Previous • Date Previous • Date Next • Thread Next |
