Re: [openvrml-develop] Re: Problem rendering from one browser into multiple/changing openvrml::gl::viewers

[Braden M. <br...@en...>]

On Thu, 2006-01-26 at 23:18 +0100, Michael Sögtrop wrote:
> Hi Braden
> 
> > I think I do not understand how your "view arrays" work. They are an
> > array of viewer::object_id? How are they indexed?
> > 
> > Don't you need an associative array (of whatever implementation) in
> > either case? It seems to me you either map node* to 
> > viewer::object_id in
> > the viewer, or you map viewer* to viewer::object_id in the node.
> 
> Those nodes in a scene that are creating references in the view get a
> unique ID that is counted up from 1. The IDs can be managed by the
> scene or browser and IDs should be recycled if a node is deleted, so
> that the IDs are usually dense and can be used as direct array index.
> What the array contains depends on the view, I would say. A GL view
> might store GL list indices. A different view might store something
> else. How do you like this concept?

I see; so it's a specialized kind of associative array.

Clever; but it strikes me as a premature optimization. My inclination
would be to use an off-the-shelf component (i.e., std::map), and later
replace it if it proves inadequate. I appreciate the memory analysis
you've offered; but as far as I'm concerned there are bigger fish to
fry; so I favor the solution that involves Less Code.

BUT... if you're doing the work and you want to implement this, it's
your call. For a patch to OpenVRML, though, I would like to see this
data structure remain consistent with the Pair Associative Container
concept[*], even if it doesn't fully model it.

[*] <http://www.sgi.com/tech/stl/PairAssociativeContainer.html>

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>