Dick Hollenbeck a écrit :
<skipped>
> 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?
I must say i like this idea.
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
These geometric transforms must be handled by Kicad code, not by a
Graphic Context.
Hit-testing needs this, but also plotting, and mainly DRC calculations.
