kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Torsten Hüter wrote:
> Hi Marco,
> 
> Yes, you're right, the additional cost is another library to maintain. However the bonus is, that it helps to accelerate the drawing speed - exactly because it was optimized for speed. AFAIK even antialiasing should work. It's well supported for Linux / Windows (mingw) / Mac OS X.
> I could imagine that for KiCad is a abstract graphics layer is created and different rendering engines are used as plugins (like for instance some emulators use).
> I'll play with it at the weekend.

Torsten,

You will need more than a weekend to play with the Kicad drawing code.
I am speaking from experience here. The problem with using any new
device context to do the drawing will not be the device context itself
but the current design of the Kicad drawing code. This has been
discussed before. I do not believe the problem lies completely with
wxDC but rather that Kicad maintains it's own coordinate transformation
(scale, offset, polarity) code outside of wxDC. These transformations
get performed by wxDC irregardless of whether you use them or not. By
default wxDC sets the scale factor and the polarity to 1 and the offset
to 0. If you look at source code for wxDC::DoDrawXXXX() methods, they
all call the LogicalToDevice() method to perform the coordinate
transforms before calling the platform specific low level drawing
functions. So Kicad effectively calculates all drawing coordinates
twice for each draw method call. The other problem is that the
coordinate scaling, offseting, polarity, and transformation code in
Kicad exists in different classes and functions all over the place. I
would like to see a more measured approach to solving the current
problem. Now that there is a KicadGraphicContext class, I propose the
following:

1) Move all of the drawing code in gr_basic.cpp into KicadGraphicContext
and eliminate the global variable ActiveScreen.
2) Perform all of the scaling, Y axis polarity inversion, and transforms
in KicadGraphicContext.
3) Move all of the coordinate offset code calculations into
KicadGraphicContext.
4) Add the clipping rectangle to KicadGraphicContext and remove it form
the parameter list of all the drawing object draw methods.
5) Use the same wxDC method names for setting, getting, and transforming
coordinates between device (screen in Kicad) and logical (drawing in Kicad).

This has the advantage of not being too disruptive to svn trunk, all of
the coordinate manipulation code in one class, no global variables
required to perform drawing, and provides an easier path to move the
coordinate manipulation code back into wxDC. Once this is complete,
using the more advanced graphics contexts like wxGCDC or SFML should be
fairly straight forward. Attempting to do use an advanced DC before you
fix the Kicad drawing code will be an exercise in futility. I know
because I tried it and found out the hard way. The best thing I can say
about the time I spent attempting this is that I have a pretty good idea
of what is involved and a clearer idea of how to move forward. You are
always free to work on what ever you wish. That is the beauty of open
source software. I just want to let you know ahead of time what you are
getting yourself into. I plan on working on this after the next stable
release of Kicad.

Wayne

> http://redkiing.wordpress.com/2009/08/05/why-sfml-rocks-and-why-you-should-use-it/
> 
> Bye..
> Torsten
>

<<< snipped >>>