kicad-developers team mailing list archive

["jean-pierre.charras@..." <jean-pierre.charras@...>]

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.

--
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 :
GIPSA-LIS - INPG
Rue de la Houille Blanche
38400 Saint Martin d'Heres