← Back to team overview

kicad-developers team mailing list archive

Re: zoom steps


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.

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.

Jean-Pierre CHARRAS

Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex

Recherche :
Rue de la Houille Blanche
38400 Saint Martin d'Heres

Follow ups