kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

jean-pierre.charras@... wrote:
> Dick Hollenbeck a écrit :
> > Jean-Pierre,
> >
> > Today I had some "close in" work to do in PCBNEW, while aligning some
> > zone boundaries which were not on grid. I could not get the job done
> > effectively without the following change to the zoom factors and zoom
> > travel.
> >
> > Please advise again the problem with the 5 entry. Maybe that can be
> > fixed, I'm game to help with it.
> >
> > Dick
> >
> > This works for me:
> >
> > static const int PcbZoomList[ ] = { 5, 10, 15, 22, 30, 45, 70, 100, 150,
> > 220, 350, 500, 800, 1200,
> > 2000, 3500, 5000, 20000 };
> >
> > in classpcb.cpp
> The problem i found on my computer (under kubuntu 8.10, does not 
> happen under XP) is when displaying filled areas.
> This can be noticed with the demo interf_u.brd, at zoom level 1, when 
> using zone filled using polygons.
> when zones are filled using the polygon mode, and mouse cursor on left 
> side of the board, filled areas are incorrectly displayed.
> Of course this does not happen if you are using the filling mode by 
> segments.
> I am thinking at 0.5 zoom level (or for large boards) this problem 
> more frequently happens
>
> For me it is clearly an integer overflow in drawing routines.
>
> I found these problems when i wrote kicad draw functions a long time 
> ago under W98 (coordinates were handled by 16 bits integers)
> and linux with arcs.
> This explains what kicad has build-in clipping functions inside draw 
> functions, and send clipped draw objects to wxDC.
> these clipping functions are not pixel accurate, they are intended to 
> avoid overflow problems.
> (They are also useful, as you know, in PostDirtyRectangle)
>
> Unfortunately polygons used to draw filled areas can have a lot of 
> segments (20,000 to 40,000)
> and clipping before send them to wxDC draw function takes a too long 
> time to be useable.
>
> Of course we can use only the filling mode by segment to avoid this 
> problem (this problem is the reason i wrote this option),
> but using polygons is also a good idea (i believe): filled areas are 
> very clean (when working!).
>
> Any idea in welcomed.

What we did for the Windows problem was give the wxWidgets team a simple 
example that exhibited the problem, better yet it was one of their demo 
programs modified.

We should do the same for this bug (post a small source code example), 
and then baby sit the bug, by posting reminders on their mailing list to 
a bug report URL until we can get somebody on the wxWidgets team to 
either fix the problem or say it is coming from below. Then if coming 
from below, move to the GTK team.

Since on Linux it is not crashing, I think the user can live with the 
occasional drawing glitch. I have seen this in geda gerbv also. The 
value to user experience of the close in zoom trumps the rare drawing 
bug in my opinion.

So along with posting the example with a bug report, for now go with an

#if def Windows kind of test for the zoom array. Windows is the odd 
duck, it should get the special test.

But include in the C++ source code a link to this thread so that young 
whipper snappers who come in later with a better idea can understand the 
road traveled.

Dick