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

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




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.

Thor

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