All graphic objects should implement Renderable and be easily composeable

[wobster]

I've mentioned this issue before here:
http://forum.worldwindcentral.com/sh...ad.php?t=21928
but as I've used WW more recently for more complex rendering tasks (text+icon+polygon+velocityVector and annotation per entity), I am convinced that all graphics objects such as Marker, UserFacing Icon, etc. should implement Renderable and should be able to simply be added to the RenderableLayer or perhaps a new RenerableList that can contain Renderables including other RenderableList. This would make it easier to compose a given object with any of the graphic objects available within WW such as an airplane with a velocity vector with a text label below it without having to resort to using 3 or 4 different layers. (Sometimes you do want to break up the attributes into separate layers and other times you don't.)

I realize that it is suggested in the literature and related WW posts that it is more optimal to render large lists of objects that are of the same type (no context switching required). It might be worthwhile to benchmark the rendering to verify that the performance is much slower. If it is, perhaps the Renderable layer could break the lists of Renderables into different types (or contexts) and then render each type of group separately under the covers as a performance optimization? (I imagine the gaming industry must have a solution for this type of thing..)

Thanks!

[tag]

Your point's noted.

We've tried to make it possible for app developers to extend or replace functionality with their own without having to rewrite the full system. We will never satisfy everyone's needs and we don't want to hold them up because of it. In the case you mention, creating a Renderable should be only a matter of making a subclass that provides that interface, and similarly for a hierarchical "RenderableList".

If it's not possible to extend or replace something, then that's a problem we need to address. (We already know of several such cases.)

[wobster]

Originally Posted by tag

Your point's noted.

We've tried to make it possible for app developers to extend or replace functionality with their own without having to rewrite the full system. We will never satisfy everyone's needs and we don't want to hold them up because of it. In the case you mention, creating a Renderable should be only a matter of making a subclass that provides that interface, and similarly for a hierarchical "RenderableList".

If it's not possible to extend or replace something, then that's a problem we need to address. (We already know of several such cases.)

Since this is only version 0.6 of the API, I was hoping that there was still time to make some fundamental changes that would unify the object model more. I've seen many benefits of having a common base class/interface such as Swing's JComponent (http://java.sun.com/javase/6/docs/ap...Component.html ) or OpenMap's OMGraphic (http://openmap.bbn.com/doc/api/com/b...OMGraphic.html ). Each component knows how to render itself and can be easily added to another component or list of components as you know.

I'm seeing some inconsistencies in the WW APIs where sometimes the layer does the rendering and sometimes the Graphic does it. I think it'd be nice to unify the approach to make it easier to compose more complex graphics and to not confuse the application programmers with the different variations.

I realize that I can subclass each one, but that means everybody who uses WW and wants a singly rooted structure would have to do this. Why not do it at the original source so everybody doesn't need to do this?

Don't get me wrong though, you all have done great work and it is terrific that WW is open sourced. I'm looking forward to seeing many popular applications based on this product. I just thought you might like some feedback from an end users on some of the API usability issues in order to improve the base product even further.

Just my $.02,

Rob

[wobster]

Perhaps a SceneGraph approach:
http://www.openscenegraph.org/projec...ase/SceneGraph
would help the performance issues related to objects rendering themselves?

[tag]

Thanks for the feedback. Please don't get me wrong, we do want input, and comments such as yours are helpful and do influence the design. But I also want to emphasize that the major WWJ design goal is the ability to extend and replace.