kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> 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.

I agree. The 0.5 zoom level comes in handy.

> 
> 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.

And this boys and girls is why cross platform development in C/C++ is
really difficult.

Wayne

> 
> Dick
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>