Re: Graphics objects -- yet more design descisions

On Sat, 17 Jun 2006, Shai Ayal wrote:

> Hi fellow object graphics developers (in other words: Bill)

Hi there.  I think that we are now joined by Muthiah as well.

> Thus a quiver graph would polute the axes with many child lines, each
> and all of them trivial (i.e. just connecting two points) costing
> memory and time overhead of many objects.
>
> For this reason I am now a bit in favour of making quiver an object in 
> it's own right, just like a surface can actually be thouhg of a 
> collection of patches, but still gets it's own object type.
>
> The pros:
> * avoid polluting the "handle space" with 100s of trivial line objects
> * memory overhead and rendering time greatly reduced
>
> The cons:
> * a new, non matlab(R) compatible object type
> * not entirely consistant with the object graphics idea where high
> level graphs do not get a dedicated object (i.e. no contour, plot,
> pcolor object types)
>
> What do you say?

I agree with the pros and the cons.  I think that I have a somewhat better 
idea (hopefully you'll think so, too).  It encompasses both of the pros 
and somewhat mitigates the second con.

I had the idea a while back for a "GroupType" attribute on the group 
object.  This attribute would allow a backend to better understand some 
group objects (for this example "quiver" could be the attribute of the 
grouptype).  If the group object had a group type, then the backend (if it 
understood the group type) would be guaranteed that any sub-objects were 
"standard" for whatever additional attiributes were stored under the group 
(I'll get back to this in a minute).

You have given me the additional idea that the sub-objects could be 
created by having a GroupCreationCallback attribute that would create all 
the sub-objects.  If the backend doesn't understand the grouptype, then it 
could call the GroupCreationCallback function and all sub-objects would be 
created.  If the frontend sees that there are child objects and a 
GroupCreationCallback function, it would run that callback on the group 
upon any modification to the group object and it would not allow direct 
modification of the children (since they are supposed to be completely 
specified by the callback function).

The pros:
* When possible, avoid polluting the handle space.
* Now, arbitrarily complex graph types are easily created by anyone (not
   just the main developers).
* Several of our current object types could be rewritten like this
   * E.g. axes are a group of lines, a shape (generally a rectangle), and
     some text, and a container for other objects.

The cons:
* There are now un-editable objects
   * I think that Matlab does similar with things like bar plots in their
     handles, but they do it so that the sub-objects are editable, I guess
     they just write all objects out and assume that any changes made are
     what the user wants and they don't use any efficiency speed-ups from
     knowing the group type.
* The group type just got a _lot_ more complex.
* It's still not matlab compatible

Bill

-- 
"Drawing on my fine command of language, I said nothing."  -- Mark Twain