expect that your framerate was significantly more stuttery and inconsistent due to garbage collection
Static scenes, simple eventing. Compile the screen graph to meshes, load textures, then move the camera around. No stutter.
The trick is to avoid the GC, not thrash the heap, don't create a lot of short-lived objects.
Implementing LOD would have sped up my browser quite a bit.
The other idea was to compile VRML's DEF prototypes to Java byte code, avoiding VRML engine overhead, in which case my Java would have smoked C/C++.
My conclusion was not that my stupid simple browser was amazing, but rather the "native" C/C++ implementations were terrible. By comparison, my browser was about 5 times faster than LiquidReality, another Java-based browser.
And these days you can go ahead and create quite a few short-lived objects without worrying about it, as long as they're elided by escape analysis.
With judicious use of off-heap memory for regular structures it's simple to erase much of the crap in the heap, and reduce already-tiny GC times even further.
Never dropping a frame is another goal entirely, though, and for that I still believe you need a separated rendering/animation mechanism.
Static scenes, simple eventing. Compile the screen graph to meshes, load textures, then move the camera around. No stutter.
The trick is to avoid the GC, not thrash the heap, don't create a lot of short-lived objects.
Implementing LOD would have sped up my browser quite a bit.
The other idea was to compile VRML's DEF prototypes to Java byte code, avoiding VRML engine overhead, in which case my Java would have smoked C/C++.
My conclusion was not that my stupid simple browser was amazing, but rather the "native" C/C++ implementations were terrible. By comparison, my browser was about 5 times faster than LiquidReality, another Java-based browser.