> We were targeting NEWT, and found it much easier to just let the
> windowing system manage resources.
> 1. A GLEventListener which rendered an Ardor3D scene would work
> with anything from a simple NEWT window, to a GLJPanel.
> 2. The GLEventListener is notified about changes in the GLWindow's
> life cycle.
> * init() doesn't get called until the resource is ready
> for initialization.
> * destroy() is called regardless of the manner in which
> the process is initiated.
> 3. FrameHandler didn't seem to provide any benefit over simply
> using an Animator.
> * FrameHandler doesn't handle Updater and Canvas instances
> added after it is initialized, while GLWindow always ensures that init()
> and reshape() are called before the first display(). We wanted the
> ability to add and remove an Updater at any point.
> * The FrameHandler doesn't provide any structure. If you
> want to ensure that updateGeometricState is called after all updates,
> then you have to provide some other mechanism (e.g. look at the examples
> provided in ardor3d-examples).
> * Since Ardor3D doesn't support updates while rendering is
> occurring, it really is just a loop over the serial phases of update and
This is awesome!
Would be great if you could push your work to a public git repository,
so we can have a look.
This might also be necessary to allow Ardor make their choice :)
BTW .. I cannot see why Ardor should be OK with this,
ie. an orthogonal toolkit approach besides the 'official solution'.
If not hosted within their codebase, we may be able to host it as a plug-in.
On Monday, November 22, 2010 19:34:29 snmvaughan [via jogamp] wrote: