kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Wayne Stambaugh wrote:
> 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:

This seems like a generally sound concept, and I offer some further 
considerations below:

> 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).


On 5) these should be in-lines if they are simply wrappers. Note that a 
full move to a wxGraphicsContext() would not end up using these 
functions, but rather the path oriented ones which are then stroked 
later. So your 5) is mostly throw away code I think. But this does not 
significantly reduce the usefulness of the entire strategy as a 
migration model.


More aggressively, I wonder if we need this intermediate step of using 
KicadGraphicContext hiding wxDC? Why not go directly to 
KicadGraphicContext hiding wxGraphicsContext?


When using transforms:

How can we do mouse hit testing when the transform is done within wxDC 
or wxGraphicsContext? If for example a pad is drawn rotated from an 
unrotated form (without transform), and the rotation is accomplished 
with a transform, then how can we do hit-testing on that rotated pad?



Dick