kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

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

> I think currently the pad's coordinates are modified as a pad is moved 
> or rotate within the footprint editor, so you don't actually have a 
> transform on the pad, likewise for the footprint. Another data model 
> could be conceived where the pad definition is simply instantiated with 
> its own transform.
> 
> 
> Food for thought, and trying to keep us from talking past each other. 
> (I had always assumed we were talking about case B), but I think now 
> this has not been the case.)
> 
> 
> Dick