kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

jean-pierre.charras@... wrote:
> Wayne Stambaugh a écrit :
>> Dick Hollenbeck wrote:
>>> Wayne,
>>>
>>> were you going to allow a 1.5 magnification on each step. I thought
>>> you had set out down that path.
>> I have been working on it indirectly. The last few commits I've made
>> were in a vain effort to clean things up a bit before tackling the new
>> zoom implementation. Like many things in Kicad that seem like they
>> should be relatively trivial to implement, there always seems to be some
>> hidden gotchas that jump up to bite you. The current device context
>> (drawing) implementation is very fragile. I am not sure why the
>> capabilities of wxDC were not used for drawing. I have looked at
>> several examples as well as the source code for wxDC and cannot
>> understand why much of what is already implement in wxDC was basically
>> reimplemented by the various drawing, clipping, scaling, etc. functions
>> in Kicad (see gr_basic.cpp) . This is one of the reason it's taking
>> longer than I had hoped. If Kicad required some special drawing
>> functionality, why not create a class derived from wxDC? This makes
>> making changes to the drawing code tricky. You have to find every place
>> in the code where zooming is touched and make sure you don't break
>> anything else. I was initially thinking of fixing the drawing code
>> first so that the zoom code would be trivial to implement. I really
>> don't like to do things twice if I can avoid it. However, fixing the
>> drawing code is a major job fraught with lots of potential breakage. I
>> guess I can break my own rule and implement the new the zoom in the
>> short term. Maybe there is some way for me to design it so that will
>> cleanly drop into any updated drawing code.
>>
> Wayne,
> thanks for your very good job in kicad code cleaning.
> Users do not see always results, but this is very important to allows 
> future enhancements of kicad without a lot of bugs.
> And developers know this is *very* important.
> 
> Yes , Kicad manages a lot of things (zoom, clipping ...).
> Why do not use the capabilities of wxDC ?
> - I discover a lot of things when writting kicad (i learn C++ with it). 
> And in 1992 a lot of things were very differents W95 did not exists);
> In fact i started kicad when i find a free 32 bits compiler (the 
> DJGPP compiler, from GCC) and a decent graphic library : LIBGRX) under 
> MSDOS and Linux.
> Linux was just started and was *not* what we know now.
> - All draw functions were first written for LIBGRX, a dos/linux graphic 
> lib that does not know wxDC capabilities (but that works very well, and 
> very fast)
> This explains some oddities.
> When i started Kicad using wxWidgets (under Linux an W95) i found major 
> problems:
> - Under W95 and Linux, Drawings were very slow (today of course, 
> computers are faster, but we can notice complex filled copper areas are 
> always slow).
> (and use clipping at wxDC level was slower than clipping at kicad level)
> - I started using wxWindows 1.68, that did not have all the features of 
> wxWidgets 2.8 (but, to compensate, a lot of bugs more...)
> - But mainly * wxDC did not work * in many cases.
> I explain:
> Under W95, W98 graphics coordinates were managed with 16 bits 
> coordinates values (I do not know about XP and VISTA).
> So under pcbnew, all drawings coordinates overflow at small values 
> for zoom (i.e. zoom 1, 2 ..), and clipping was mandatory. (this seems 
> not the case under XP)
> So i couldn't use wxDC zoom feature "as this".
> Perhaps are you thinking this cannot happen under Linux (that handles 
> coordinates with 32 bits value)
> Alas! false.
> When drawing Arcs and circles, some coordinates overflow appears 
> (perhaps in 32 bit integer intermediate calculations using mult.).
> I see now (under Linux, not under XP) same problems when redraw filled 
> copper areas by polygons
> (at least on my computer: KUBUNTU 8.10, at zom level 1, for 
> interf_u.brd sample, using polygons to fill areas).
> This is the reason i wrote the filled areas by segments as an option to 
> fill copper areas :
> In case of overflow when redraw copper areas one can use segments 
> (they are clipped at kicad level before they are drawn)
> 
> So before using clipping only at wxDC level, be sure it works when you 
> are using Zoom 1 (or 2 or 4) mainly when:
> drawing filled polygons (they are not clipped in kicad, because this is 
> a consuming calculation time, one cannot use simple algos)
> drawing arcs
> drawing circles.
> 
> This is true for XP and Linux.
> For instance, under Linux, i saw (a long time ago) arc overflows with 
> pixel coordinates > 4095!
> I hope this is now not the case.
> 
> Note: because clipping is made in kicad mainly to avoid overflows, and 
> reduce drawing calculation time, clipping is not pixel accurate.
> So arcs and circles use a very simple clipping algorithm. (they are 
> drawn or not)
> 
> I did not say: do not use wxDC capabilities,
> but i believe the clipping at kicad level remains useful, and perhaps 
> (Alas!) mandatory for some graphic shapes.(to be tested for arcs ...)
> Of course, clips graphic shapes at kicad level, uses only user 
> coordinates and uses wxDC zoom capabilities (there is some code in 
> graphic functions in gr_basic)
> could be an interesting approach.
> 
Thanks for history. It helps to explain some of the design decisions.
I didn't started using wxWidgets until the 2.2 branch. I also have some
issues that I'll need to keep an eye on as I make changes to the drawing
code. I hope there is no need to continue supporting Windows 9X. I do
not have access to machine runs Window 9X so I would have no way to
verify that I didn't break anything. Not that I am particularly
interest in supporting 9X but someone else may care.

Wayne