Author stefan
Recipients neiljp, nicholas
Date 2003-04-03.15:06:04
Nick Lewycky wrote:
> Nick Lewycky <nicholas@fresco.org> added the comment:
> 
> stefan, wasn't the idea here to allow us to save
> memory storage in the PathImpl? Could you convince
> me that your complex IDL types are going to be
> more memory efficient than:
> 
> enum PathSegmentType { move, line, conic, cubic };
> struct PathSegment
> {
>   Vertex to, cp1, cp2;
>   PathSegmentType type;
> };
> 
> in straight C++ (not burdened with CORBA anything)?
> 
> ________________________________________
> Fresco issue tracker <issues@fresco.org>
> http://issues.fresco.org/task139
> ________________________________________
> 
> 

Two things:

* my suggested path is more flexible than yours,
   as it allows more than one curve type, so there
   is more than memory-efficiency

* the path idl as I suggested it doesn't involve
   *any* CORBA, it is mapped to straight C++

Please consider the extreme (but most frequent)
cases, where you have a path with a single segment
which is a 'polyline'. The data you'll effectively
see is:

+------------+
|    Path    |
|+----------+|
|| Polyline ||
||+--------+||
|||Vertices|||
|||        |||
||+--------+||
|+----------+|
|   closed   |
+------------+

i.e. there isn't a single control point. In your case
you'd carry 2n redundant vertices with you for a polyline
consisting of n vertices, and if we would generalize your
case to support nurbs you'd also get weights and knots
that wouldn't serve anything.

So I'm trying to make the data types as specific as possible
for a given curve type, and then use a union to get the
necessary flexibility.

Also (in reply to your other message), the (de)composition
I show merely reflects the conceptual separation of items
that make up a path. I'm not suggesting that we have to
keep the Path API as transparent as that.

I can see your point of wanting to restrict access in some
way or another (though I can see cases where I want to
modify vertices or other data in place). Let's first iron
out the underlying path *model*, and then refine the API
to access and modify it, ok ?
Files
History
History
Date User Action Args
2003-04-03 15:06:06stefansetrecipients: + nicholas, neiljp
2003-04-03 15:06:06stefanlinktask139 messages
2003-04-03 15:06:06stefancreate