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