Stefan Seefeld wrote:
> 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...

Oh is that what you're worried about. Well, if it helps, the CORBAized 
version of the Java Shape interface[1] I modelled this after would 
actually be:

PathSegmentType currentSegment(out Vertices);

Where what they actually use in Java is a double[6] or float[6].

For the DrawingKit, this would mean only one dynamic allocation of the 
Vertices with a length of three per draw_path API call, not per path 
segment. And if that's still too nasty for you, we could allocate that 
Vertices *once* when the DrawingKit is cloned and use it evermore.

Well, actually, we'd have a problem with your arbitrary length NURBS, 
wouldn't we, not fitting in Vertices.length(3). And doubtless you'll 
complain again about the two wasted spaces when it's only a line segment 
and not using the control points.

I suppose then what we would do is create the PathSegment in the add_* 
call, and return a reference to that when get_segment is called. We can 
even allow them to modify the Path through the reference we returned.

void get_segment(out PathSegment ps);

should be appropriate, yes?

[1] - 
http://java.sun.com/j2se/1.4.1/docs/api/java/awt/geom/PathIterator.html

> (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.

The granularity isn't the issue I think we should be focusing on, it's 
the *usability*. Especially for programmers with little or no CORBA 
experience. My opinion is, the CORBA sequence interface is bad and I 
don't want to force client authors to use it any more than I must.

>>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).

No offense, but I'd rather you didn't try to spoil the architecture here 
by making this Path the one and only place where we don't use CORBA 
pervasively. If you want to decree that we should start removing CORBA 
between the scene graph and renderer, then you can do that later. Please 
don't start hacking up an otherwise perfectly good design. This curved 
path work is absolutely essential for Fresco to be used seriously as a 
GUI toolkit. It is not a toy for you to try alternate approaches and 
architectures.

The good news is that if we do decide to start such work, we can do so 
easily since both C++ calls and cross-CORBA calls look the same in terms 
of the code syntax.

That said, if I'm not mistaken, my Beveller implementation already does 
use direct C++ calls:
   PathImpl path = new PathImpl();
   path->add_lines(v);
is not a cross-CORBA call. Only when I call "drawing->draw_path( 
path->_this());" does CORBA get involved, which is exactly what our 
design currently mandates. How is this different from your suggested 
"non-corba [convenience] functions (inside libBerlin)"?

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

The DrawingKit will have to check that itself (and 
LibArtDrawingKit::draw_rectangle() already does). The point is that we'd 
add a Rectangle segment type instead of adding four lines.