Re: Interesting interactions between objects and renderers

[Cyrille Chepelov <cyrille chepelov org>]

Le Sun, Mar 24, 2002, à 06:56:35PM -0600, Lars Clausen a écrit:

> 1) Non-straight lines (arc & bezier) are suddenly rendered at a different
>    place than where they're checked for mouse clicking.  To move a bezier
>    with an arrow, I head to click outside the line.  So whatever checks for
>    mouse clicks will have to know about the transformation, and ought to
>    also include the arrowhead in the clickable area (though that may be
>    overkill).

I've had working code to build a segment out of a bezier; ie, trim a given
linear length off one or the other side of the bezier, and still keep a
segment of bezier which can coincide with the original one. It's been
written with dia arrows in mind. Here's it, attached here (I've not touched
it since Apr 8, 2001, so YMMV with that)

As for transformations: what does sodipodi ?

One idea which has been floated around at one time was to do a kind of a
"transformation box". Ie, objects which are put in that transformation box
are all affected by the same transformation (think group objects on
steroids). It turned out not to be that great an idea, from a UI point of
view; however, we could imagine a stack of "transformation objects" tacked
on the renderer by objects. For renderers which actually know what is a
transformation and a stack (the usual suspect indeed), that maps nicely. For
the rest, we just have the transform coordinates on the top of the stack
when we need them.

Objects would still be required to compute their non-transformed (or
already-transformed) bounding box, and we need to make the mouse click code
aware of the transforms the objects is applying onto itself -- I really can
see this going as a generic layer over the existing routines, for the
general case of whole-object transforms. For object-part transforms, the
object will still have the flexibility to request a specific transform
anyway, so I don't really see a problem here.

My take is that we should not even consider any caching whatsoever until
gprof tells us to put our nose there. Until then, let's just assume we have
a fast enough CPU (and I still use my P133...). We've already got a lot of
CPU wast^W^WXML processing already, we can do a couple geometric
transforms...

        -- Cyrille

-- 
Grumpf.