[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Public WebGL] Latency issues, ideas for next WebGL revision
- To: firstname.lastname@example.org
- Subject: [Public WebGL] Latency issues, ideas for next WebGL revision
- From: Thor Harald Johansen <email@example.com>
- Date: Wed, 09 May 2012 04:04:08 +0200
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- Sender: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
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
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
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
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
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 email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: