4 ms·

Pointerrawupdate events: https://w3c.github.io/pointerevents/#the-pointerrawupdate-event https://w3c.github.io/pointerevents/#the-pointerrawupdate-ev... would h

by wffurr 2y ago

Pointerrawupdate events: https://w3c.github.io/pointerevents/#the-pointerrawupdate-event https://w3c.github.io/pointerevents/#the-pointerrawupdate-ev... would help with that. If tearing is Ok, the canvas can be desynchronized and updated immediately. We can get 10 msec inking latency with those on a 60 Hz display.

CyberDildonics 2y ago
Is inking latency the new pixel to pixel latency or input to pixel latency? I like to keep up with the new names for old things.
- tonmoy 2y ago
  I’m guessing “inking” is a autocorrect of a typo that was meant to be “input”
  - dleeftink 2y ago
    From hereon it shall be inking [0]: https://en.wikipedia.org/wiki/Inking https://en.wikipedia.org/wiki/Inking
  - wffurr 2y ago
    Actually I was referring to drawing with a stylus on a drawing app like Google Keep drawing notes or https://canvas.apps.chrome/ https://canvas.apps.chrome/.
- modeless 2y ago
  The features he's talking about were added to Chrome for ChromeOS/Win8 tablet stylus drawing support, which they refer to as "inking". They're kind of a specific fast path for that use case. They were not tested for any other use case and as a result tend not to be usable in practice due to various caveats, unfortunately.
modeless 2y ago
In the past I have experimented with pointerrawupdate and desynchronized, and I was unable to reproduce any latency benefit in practice. These features have a lot of caveats and are not reliable, in my experience, which is probably why practically nobody uses them. It's way too easy to fall off the fast path, if the fast path is even supported on your platform at all. Also, native apps have a lot of options to reduce latency without any risk of tearing artifacts, and it's unfortunate that web apps don't have access to those options. The web has a long way to go to match native on the latency front and there really hasn't been meaningful progress in that direction. I would like to experiment with pointerrawupdate and desynchronized again. But I'm currently relying on Emscripten's SDL implementation for input and drawing, and replacing or modifying that is daunting. After all, this is just a fun side project for me. A much easier and more widely supported latency fix would be to use a blocking API like WebGL's ReadPixels to synchronize the content process and GPU process and defeat the deep frame pipelining that the browser usually falls into, at some cost to performance. I plan to try that first.

by wffurr 2y ago

CyberDildonics 2y ago

Is inking latency the new pixel to pixel latency or input to pixel latency? I like to keep up with the new names for old things.

tonmoy 2y ago
I’m guessing “inking” is a autocorrect of a typo that was meant to be “input”
- dleeftink 2y ago
  From hereon it shall be inking [0]: https://en.wikipedia.org/wiki/Inking https://en.wikipedia.org/wiki/Inking
- wffurr 2y ago
  Actually I was referring to drawing with a stylus on a drawing app like Google Keep drawing notes or https://canvas.apps.chrome/ https://canvas.apps.chrome/.
modeless 2y ago
The features he's talking about were added to Chrome for ChromeOS/Win8 tablet stylus drawing support, which they refer to as "inking". They're kind of a specific fast path for that use case. They were not tested for any other use case and as a result tend not to be usable in practice due to various caveats, unfortunately.

modeless 2y ago

In the past I have experimented with pointerrawupdate and desynchronized, and I was unable to reproduce any latency benefit in practice. These features have a lot of caveats and are not reliable, in my experience, which is probably why practically nobody uses them. It's way too easy to fall off the fast path, if the fast path is even supported on your platform at all. Also, native apps have a lot of options to reduce latency without any risk of tearing artifacts, and it's unfortunate that web apps don't have access to those options. The web has a long way to go to match native on the latency front and there really hasn't been meaningful progress in that direction. I would like to experiment with pointerrawupdate and desynchronized again. But I'm currently relying on Emscripten's SDL implementation for input and drawing, and replacing or modifying that is daunting. After all, this is just a fun side project for me. A much easier and more widely supported latency fix would be to use a blocking API like WebGL's ReadPixels to synchronize the content process and GPU process and defeat the deep frame pipelining that the browser usually falls into, at some cost to performance. I plan to try that first.