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

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

After exchanging some emails with Boris Zbarsky, it would seem that my Mozilla frame rate issue was due to hardware compatibility. With Opera using hardware acceleration as well, it would seem that compositing is not going to be an issue, so go ahead and discard that part of my message.

Can't seem to get WebGL working in the Opera 12 Beta, even after enabling the appropriate flags for WebGL and hardware acceleration in about:config, but if they don't do triple buffering by default either, that part of my message becomes a Chrome specific issue.


On 5/9/2012 4:04 AM, Thor Harald Johansen wrote:
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:


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.

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