Edit: I realize what I saw is a textured version of what you are describing.

The 3D perspective page http://webglfundamentals.org/webgl/lessons/webgl-3d-perspect... clearly describes the rasterization phase as having 3D: the automatic perspective divide and the triangle clipping to a 3D space. Clip space being 3D seems very strange if WebGL is only a 2D API.

My suggested patch would be to rephrase it for the beginner. "WebGL is largely a 3D rasterizing API and not a fire-and-forget scene rendering solution."

If WebGL were only 2D it would be trivial to implement 3D without shaders in <canvas> -- and that is not true, canvas cannot rasterize 3D triangles.

The graphics are done on an ordinary timer which redraws based on the cached video state from the audio callback. JSMESS could probably do the same.

You'll always have a serious problem when there is more than one timer. If I could change the APIs, I'd add a requestAudioVideoFrame() timer callback where you would supply both the video (rendering) and the audio buffer for a given segment of time. That would also give the browser more control over the situation.

http://en.wikipedia.org/wiki/HotJava

The stackexchange commenter moans about graphics performance in Java. I helped write the Magician OpenGL bindings for Java in the '90s (the Java API side was all me, which Sven of JOGL basically copied). My VRML browser was just as fast (fps) as the available VRML browsers written in C/C++. With JDK 1.1.

Nowadays, Java and OpenGL go together like peas and carrots. Exhibit A is MineCraft.

A good buddy of mine does all his projects in Java and OpenGL. The latest is the awesome 2D skeletal animator called Spine at http://esotericsoftware.com. I couldn't imagine him doing it on top of any other stack.

With respect, I find your claims dubious. I would certainly buy that your top framerate was competitive. I also expect that your framerate was significantly more stuttery and inconsistent due to garbage collection (or else written in such a devolved form of Java that you really might as well write C++ anyway).

The problem is not Java's execution speed. It's that garbage collection is the death of responsiveness.

> Nowadays, Java and OpenGL go together like peas and carrots. Exhibit A is MineCraft.

Minecraft's performance characteristics are pretty bad for the fairly trivial rendering work being done. (It's improved, but it's still not great.) And writing code with LWJGL/JOAL is gross relative to similar code in C++--I have done both. You don't get anything for tying yourself to the JVM except, in a weird and mostly self-destructive way, the 'freedom' from understanding your object lifetimes and deterministic destruction.

I've used libgdx and XNA/MonoGame extensively and have gone back to C++ because both are fairly limited in their usefulness. libgdx helps by hiding a lot of nasty API issues--and Mario and company are super good at what they do--but what it gives you is generally taken away by the limitations of the JVM in a client context (limited platform support, the infuriating Dalvik/Hotspot divide, That Frigging GC Again...). Writing up some pretty minor glue code between windowing, input, audio, and graphics isn't that bad. And, perhaps more importantly, you'll actually understand how it works. (I've spent the week fighting with OpenAL. I'm glad I did. I've learned a lot and can recognize the failure cases and can do something about them.)

> A good buddy of mine does all his projects in Java and OpenGL. The latest is the awesome 2D skeletal animator called Spine at http://esotericsoftware.com. I couldn't imagine him doing it on top of any other stack.

Spine's pretty impressive, but there's not much in it you couldn't do with ease with Cocoa/Obj-C[++] or Qt or even WPF and .NET. It's also a misleading example, though, because tooling generally has much looser latency requirements than user software and so the severe weaknesses of JVM client applications are less readily apparent than in an application that needs to hit 60fps all day every day.

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.

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.

A key problem (and measure of quality) for me is reducing the latency. I've had trouble getting continuous sound with less than a quarter second of buffer. (Ideally, I'd like to achieve smooth sound with only 17ms of buffer/lag). Another browser to work with will help, and, maybe the IE team will take notice.

FWIW, the cause was getImageData(0, 0, w, h) returning 4wh pixels and not w*h as I naively expected.

Porting or re-implementing these kinds of oddball programs is a way to explore the possibilities. How fast can Javascript really run? Are the graphics APIs sufficient? Should browsers support USB joysticks? Cameras? In other words, helping to see where the straightjacket is loose. And, ideally, encouraging the browser developers to cut some of the straps.

Second, I imagine they will use the devices as actual phones to contact the employees. No need to PA a clerk to pick up a phone. Just forward the call.