← Back to team overview

kicad-developers team mailing list archive

Re: "Close in" work in pcbnew


jean-pierre.charras@... wrote:
Dick Hollenbeck a écrit :


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

Please advise again the problem with the 5 entry. Maybe that can be
fixed, I'm game to help with it.


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.


Follow ups