kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

jean-pierre.charras@... wrote:
> 
> 
> 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.

This is what wxGCDC does. It effectively makes a wxGraphicsContext look
like a wxDC. This way you get some of the wxGraphicsContext
functionality without having to change all of your drawing code. It has
the advantage of being able to easily fall back to wxDC if the
wxGraphicsContext performance is unacceptable. You would still have to
implement the advanced GC features such as paths and transforms. It
also allows the changes to be made in small steps minimizing the chances
of having completely broken drawing and/or printing code in SVN trunk.

>> 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?

wxDC provides CalculateBoundingBox(), MinX(), MinY(), MaxX(), and MaxY()
and wxGraphicsPath provides Contains() and GetBox() for hit testing.
These are determined by where the object is drawn on the context in
logical (drawing) coordinates. If you use the coordinates where the
object is drawn then it should map to the cursor position using
wxDC::DeviceToLogical(). There is an undocumented class wxDrawObject
defined in wx/dc.h that provides a base class for handing bounding boxes
for drawing objects.

>> Dick
>>
> These geometric transforms must be handled by Kicad code, not by a
> Graphic Context.

With wxDC this is true as it does not support transforms. Although you
could easily move this into KicadGraphicsContext so that all the
transform calculations occur in one place. For wxGraphicContext I don't
see any reason why you could not make the Kicad transforms map to an
equivalent wxGraphicMatrix.

> Hit-testing needs this, but also plotting, and mainly DRC calculations.

Why do you need transforms, for plotting? Look at the way
wxPostScriptDC is designed. The draw methods just get converted to
PostScript format and written to a file as opposed to drawn on the
screen. How difficult would it be to create a GerberDC or an HPGLDC and
map the draw methods to Gerber or HPGL file format? Interestingly,
printing in Kicad uses wxDC scale, offset, and axis polarity then calls
the unscaled drawing functions in gr_basic.cpp. I don't understand why
drawing to the screen is not done the same way. I can't really comment
on DRC other than it is not directly a drawing operation so separate
transforms for DRC testing may be required.

Wayne

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