Nick Lewycky wrote:

> You want one interface for the FigureKit's Path and one for the Path
> that the DrawingKit draw_path function takes?

well, 'interface' in an abstract sense...

> I'm not sure I can disagree more. :-) I wanted the clients to get a 
> Path_var from the FigureKit, and a Very Dumb wrapper Graphic which takes 
> the Path_var from the client and calls DrawingKit draw_path with it when 
> traversed. Part of the reason is to keep only one true Path API around 
> for consistency and clarity.

I still think that there are conceptually two things, which may or may not
be lumped into a single interface: There is a low level 'war' path that
is handed over to the DK for rendering. Assuming that the DK has only
a single method to draw paths (polylines, curves, all through the same
call), it means the path passed as argument needs to be pretty versatile,
and easy/fast to access.

This means we should do everything we can to avoid unnecessary dynamic
memory allocations (such as used in method calls a la

PathSegment get_segment(in long i)

...
That's the kind of thing which kills performance...

(One reason I'm interested into this path API is that I'd like to understand
how we can get CORBA *out* of the scene graph, i.e. make the CORBA exposed
interface (i.e. the calls that are routed through the ORB) more granular.)
And I think that Path is a good topic to study this.

> If you don't value that, then we can break it into two pieces, one of 
> which is a secret between the FigureKit and the DrawingKit. Oh, and any 
> other client-side Graphics who might care, but we can safely ignore them 
> by saying "don't do that then" in the documentation.

Well, basically all graphics that render use paths (images are the only exception).
Though the vast majority will render simple things such as rectangles or polygons.
For example the 'beveled frame' (WidgetKit / ToolKit) will store a path internally
and pass it down to the DK when being drawn. I don't mind the implementer of
a Bevel to mess with path internals, if that is what we need to be fast. And even
then we could provide non-corba functions (inside libBerlin) as convenience...

Not so the FigureKit graphic that exposes a Path API: there I expect all those
nice methods like 'add_circle_segment', 'add_bezier', 'add_polyline', etc.
which *application* code will hook into (such as daVinci).

> Actually, your PathSegment in a struct makes a whole lot more sense when 
> considered as part of approach. :-)

I hope so :-)

> One thing we should keep in mind is 
> that some DrawingKits will have accelerated draw_rectangle 
> implementations which wouldn't be accelerated in draw_path. The 
> LibArtDrawingKit is currently such an example. We could work around this 
> by allowing a new PathSegment of type Rectangle so that the backend 
> could Do The Right Thing.

While I agree in general (that's why I still suggest a bezier segment, even though
it could be entirely represented as a nurbs segment), I think that it is simple
enough for renderers to detect whether a polyline is a rectangle. Also don't
forget that whether or not it is a rectangle depends on the accumulated trafo, too...

> Stefan, if this seperation is what you intended, one Figure::Path and 
> one Fresco::Path, then I'll happily use your Path internally and expose 
> only my original API from Figure::Path. Does that satisfy both of our 
> design requirements?

yes, I believe we are getting closer :-)