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

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



On Wed, May 9, 2012 at 12:54 PM, Thor Harald Johansen <thj@thj.no> wrote:
>
>> Who to bug about this... Reading through some years-old bugs: on
>> Mozilla-side I guess it's Robert O'Callahan, on Webkit Oliver Hunt.
>> Implementation on Linux GTK is easy (toggle a flag, add fields to
>> mouse events, took me a few days on Firefox), on Mac it's supposedly
>> almost as easy, on Windows you would need to go through third-party
>> driver APIs, chiefly Wintab.
>> https://bugs.webkit.org/show_bug.cgi?id=20458
>>
>> I don't know how to get more traction for this though :/
>
>
> Yeah, I just want to point out some issues with Oliver Hunt's remarks on
> that bug report:
>
> "There are multiple halfway there APIs.  The most complete is the WinTab
> API, but afaict that's not actually part of windows, but that's okay because
> it also doesn't interact with the event queue."
>
> It doesn't need to be part of Windows any more than OpenGL needs to be.
> WinTab is pretty much the OpenGL of tablets in terms of driver support.
> Photoshop and most other applications simply look for the WINTAB32.DLL
> library and link against it. It's basically the industry standard for
> tablets.
>
> "In all honesty I'm leaning towards supporting pressure information on Mac
> and Gtk, seriously trying to support this on windows seems to be an exercise
> in futility."
>
> The problem he's talking about is basically that, while WinTab can deliver
> its messages to the Windows message loop (and also sports a polling API),
> these events are delivered in parallel with the system mouse events.
>
> This happens because most tablet drivers will grab and control the Windows
> mouse cursor whenever the stylus is held near the tablet. I don't think
> there's room in the Windows message structure for all the required data. The
> more expensive tablets support tilt, rotation and other telemetry in
> addition the high-res position and stylus pressure.
>
> This of course complicates matters, but it's far from being as hopeless as
> Oliver portrays it. Mouse and tablet events arrive together in the Windows
> message queue, so it's easy to just assign the data from the previous
> WT_PACKET tablet event to the current mouse event. wParam contains the
> serial number of the WinTab packet, which can be retrieved with WTPacket().
> WinTab will then discard any prior, unretrieved packets.
>
> Most tablets also have DPI resolutions more on par with high end printers
> than consumer monitors, and the WinTab API will provide high resolution data
> to that end. In a browser API, one could either support floating point mouse
> positions through the regular DOM fields (and break a lot of JavaScript code
> in the process) or add extra high resolution fields just for tablets.

It would be great to bring your app to the web via WebGL. Your first
email raises several issues. In order to make progress on them, let's
separate them out.

 - Input latency: browser vendors are definitely aware that lower
latency for input events is needed. However, more test cases are
needed in order to make progress on this issue. If you could make a
preliminary version of your app available for testing, or come up with
a self-contained test case that illustrates when input latency is too
high and when it's acceptable, that would be helpful. I am optimistic
that input latency can be reduced to acceptable levels without
providing application control to disable vsync, which would introduce
tearing on animated web pages and result in a poor user experience.
Chrome does no triple buffering, but the input and rendering pipeline
is fairly deep; three OS processes are involved.

 - You can disable WebGL's built-in antialiasing by calling
getContext("experimental-webgl", { antialias: false }). Anisotropic
texture filtering is not enabled by default; it is being specified as
an extension at http://www.khronos.org/registry/webgl/extensions/ .

 - On any reasonably modern hardware it should not be necessary to
special-case WebGL's rendering to the screen. Specifying { alpha:
false } in the context creation attributes should be sufficient to
reduce the alpha blending overhead for the compositing of the WebGL
canvas in the page.

 - Adding support for tablets' auxiliary information is a larger
discussion that would have to occur with the appropriate web working
groups -- perhaps public-webapps or whatwg. I think the best way to
make progress on this issue would be to do a preliminary port of your
app using whatever mechanisms you need, such as Wacom's browser
plugin. Then we can collectively build prototypes in Firefox, WebKit,
etc. of cross-browser APIs exposing the additional information you
need -- tilt, pressure, etc.

-Ken

-----------------------------------------------------------
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
-----------------------------------------------------------