← Back to team overview

kicad-developers team mailing list archive

Re: wxGCDC (was Re: Re: R2217 bugs)

 

Wayne Stambaugh wrote:
Dick Hollenbeck wrote:

There can be more than one transform in play. We have yet to explain which discussion we are in, either:


A) For the case you you have only one transform for the whole graphics panel, and a single world coordinate space, then this closely matches what we have now.


Dick,

I was talking about case A, the device context transforms. For example,
currently all of the Y axis inversion is done by the object drawing code
instead of the DC. You will find NEGATE(y); and y *= -1; all over the
kicad drawing code. All of this could be eliminated by calling
wxDC::SetAxisOrientation( false, true ) in PrepareDC() before calling
the object draw methods. The scaling is done in BASE_SCREEN::Scale()
and BASE_SCREEN::Unscale(). The clipping is done by all of the
GRDrawFoo() functions in gr_basic.cpp. Typically all of this done by
the DC. In other words the kicad drawing code should always draw using
it's own internal coordinates independent of the DC. Kicad should not
have to adjust it's coordinates to correct the device context output.


B) The more elaborate case that I also wanted to talk about was a situation where you have a transform attached to each footprint instance. The footprint is defined with a given orientation, but each instance of it has the ability to rotate and translate that definition without actually modifying the definition's coordinates. Likewise the pads on the footprint, can be defined with one set of coordinates. Then each instance of that same kind of pad can have its own transform (rotation and translation). Now, when you look at the big picture for case B), you have 3 transforms in play to get to a pad. The one for the graphic panel, the one for the footprint, and the one for a given pad within a footprint.


You may be able do this with wxGraphicsMatrix. It is an independent
class for transforming coordinates. Each case you described above could
have its own wxGraphicsMatrix. wxGraphicsMatrices can be concatenated
allowing a child item to be transformed relative to its parent. It may
even be possible to use this when rendering to the display once
wxGraphicsContext is implemented.

Wayne



Yep, so now that we are on the same page B) here, my question is still a valid open one that we can eventually answer by code:

What is the cost of doing hit testing (and JPs concern about DRC) though these transforms, which can be stacked or melded as you say?

In other words, down the road as we revisit the data models, what is the cost benefit ratio for fully using wxGraphicsMatrix for each major graphics object?

I'm thinking at this point that working code will answer this question best.

Dick







References