kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Warning, rant ahead. If you are only interested in the new zoom stuff,
skip down to the last paragraph. However, if you indulge me, I would
like to impart some wisdom I gathered on my travels through the inner
workings of Kicad and wxWidgets. Let me start by saying that in order
to get the new zoom features implemented I violated at least a half
dozen of my personal coding rules not the least of which are don't
reinvent the wheel and keep it simple. But I was concerned about Dick's
eye sight, so I acquiesced.:} In my travels through the Kicad and
relevant wxWidgets source code, I came to the following conclusion that
all of the drawing coordinate scaling (zooming) and offsetting code in
Kicad is unnecessary and redundant. For all the developers who in the
past have voiced concerns about using floating point for drawing
coordinate calculations, be assured that it is already happening inside
wxDC. Granted, if no changes to the logical or user scalars are made to
the device context, then the coordinates get multiplied by 1.0 * 1.0.
They still get converted to floating point then back to integer. In
fact, all of the scaling code performed as integers in Kicad just adds
clock cycles to what wxDC already does. There is no performance gain by
doing this. Not convinced, check out the "drawing" sample shipped with
the wxWidgets source. It does not scale the drawing object coordinates
before calling the wxDC drawing methods. All it does to change the size
an position of the drawing is manipulate the user scale and logical
offset of the device context. Everything else is taken care of by wxDC
automatically. wxDC even provides functions to translate coordinates
between the logical and display units. All of this capability appears
to have been available in wxDC all the way back to at least 2.2.9 in
December 2001 (that was the oldest wxWidgets help I could find). The
drawing sample works the same on Windows and Linux (64 & 32 bits). Can
someone with OSX confirm that wxWidgets drawing sample works there as
well? If so, I think that all of the code in gr_basic.cpp and all of
the scaling and offset calculation code scattered throughout Kicad
should be remove and pushed down to wxDC where it belongs. This would
greatly simplify drawing in Kicad and having the added bonus of allowing
the use of some of the more advanced wxDC type classes such as
wxGraphicsContext or wxBufferedDC. I am willing to take on the task
(although it will probably take me a few months to complete) after the
next version of Kicad is released. I'll stop ranting now, but I have a
few more in store for a later date.

Now on to the new zoom code. Due to the coordinate scaling being
scattered throughout Kicad, I did not implement the new zoom code with
#ifdefs all over the place. I started down that path, but it was
quickly becoming an awful mess and a pain to enable and disable. I
tested everything I could think of that is zoom related and it seemed to
work fine for me. There may be some slight single pixel drawing issues
due to rounding since I had to use a scalar to get a zoom of 1.5 (known
as zoom level 15 in the new code). I have not committed the new code to
SVN yet due to talk of a new release in February. If no one has any
objections, I will commit the code in the next few days. I believe that
the risk is fairly low but I will wait. If the consensus is to wait
until after the new release, I'll hold off committing until then.

Wayne