octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OctDev] Java/OpenGL-based graphics package for octave


From: John W. Eaton
Subject: Re: [OctDev] Java/OpenGL-based graphics package for octave
Date: Wed, 25 Apr 2007 14:22:56 -0400

On 24-Apr-2007, Michael Goffioul wrote:

| On 4/24/07, John W. Eaton <address@hidden> wrote:
| > On 23-Apr-2007, Daniel J Sebald wrote:
| >
| > | Oh, I see; that makes sense.  But no one has added 'case "stemseries"' to 
the
| > | __go_draw_axes__.m file yet?
| >
| > It's not quite that easy.  If you look at the object that Matlab's
| > stem function returns, it only says hggroup for the type.  I don't see
| > anywhere that it says "stemseries" or how that is determined.  Maybe
| > it is a hidden property?  Maybe it is magic?
| 
| I don't think you have to view it that way. A hggroup object is just
| the grouping
| of other objects. When rendering a hggroup, you just have to recursively
| render the children. The actual type of the hggroup is not relevant when
| rendering, because the operation is passed to the children. The only things
| that you need to render are the core objects; all others are just combination
| of these core objects.

I'm not sure you can just pass the rendering to the children.  The
stemseries and barseries objects both have type "hggroup" but they are
apparently distinct objects because they have different properties,
and some of those properties must affect the way the object is
displayed.  So it seems to me that each of these objects must have its
own rendering function otherwise the rendering code for "hggroup"
would have to know about all possible types of hggroup objets, which
doesn't seem like a very tidy design.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]