[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] Latency issues, ideas for next WebGL revision




Hello everyone!

I'm the creator and maintainer of Sketcher, a Java-based multi-user image editor and rich Internet application, and ArtGrounds, an art gallery and community that Sketcher runs on top of.

For the purposes of this mailing list, Sketcher is what I wish to focus on, so here is a screenshot:

http://www.artgrounds.com/submission-data/104182/

Liking to be ahead of the curve, I've got an ambitious plan to port the entire application to JavaScript and WebGL.

Sketcher supports pressure sensitive graphic tablets through the JTablet API that was developed by my good friend Marcello Bastea-Forte who currently works for Apple. Wacom has developed a browser plugin that exposes a tablet API to JavaScript, and I plan to use this for my port of Sketcher.

There is a persistent pattern here, of vendors not bothering to add support for digitizer tablets to their platform APIs, despite these having been popular since the 1970s.

High frame rates and low latencies are vital for sketching, inking and coloring, a common usage case for tablets in the graphics industry. I imagine this to be important for computer games as well, and this is probably going to be the most common usage case for WebGL.

I have an airbrush stroke rendering algorithm running on the GPU right now. It is looking good, and I even managed to implement dithering, which makes a significant difference when you're performing repeated overlapping alpha blends.

From what I can gather, WebGL offers no control over such features as vertical sync and triple buffering, and this becomes very apparent when running my application in Google Chrome, which seems to turn on these things by default.

Since vertical sync on its own shouldn't introduce significant latency, I am suspecting that either Chrome or my graphics hardware is enabling triple buffering. I have disabled triple buffering in the NVIDIA Control Panel, but in my experience, these settings are often overridden by the user-space programs.

Disabling the vertical sync option in chrome://flags removes all latency issues and improves the frame rate. I have calculated the latency for 3 buffers to be 50 milliseconds, plus monitor latency. In my experience, anything over 10 milliseconds is noticeable.

I would like to disable vertical sync and triple buffering from my application code. I'd also like some control over sub-sampling and anisotropic filtering, resource hungry algorithms that my application doesn't really need. I should at least be able to request that these algorithms be disabled.

In testing my application on Mozilla Firefox, I found the frame rate to be so low that I was not able to tell if there was any latency. I assume that Firefox is still using software compositing, which leads me to another issue...

A very common usage case for WebGL is going to be a rectangular opaque 3D canvas with no overlapping DOM elements. This is a case that can easily be optimized by means of an API flag on the getContext() call. The application promises to not attempt overlapping elements, and the browser renders the WebGL canvas in-place, in a separate sub-window, on top of any other elements, similarly to how browser plugins are painted today. Appropriate OpenGL viewport cropping is performed when the canvas is scrolled out of view.

Browsers that use GPU accelerated compositing can simply ignore the flag. Browsers like Firefox will experience a significant speedup.

And that pretty much summarizes my thoughts on WebGL. I would appreciate your viewpoints, especially if you're on the WebGL standards committee.

Regards,
Thor Harald Johansen

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------