#473: Delegated Ink Trail
Discussions
2020-03-23
Rossen: I moved the issue out by couple of weeks (to April 6) as the feature authors are actively addressing the feedback provided by David and myself during last round of reviews in Wellington
2020-04-06
Rossen: David and I looked at this in Wellington. We left detailed feedback that was largely agreed upon with the authors. I pinged the author and he said the current version of the explainer is ready for review, and it has incorporated the feedback.
... If you go to the current explainer that's proposed, you'll see this one is marked as archived, because the explainer moved to a WICG repo
... we've adopted this document status policy for all our (msft's) explainers
David: I've updated the issue to use the latest URL
Rossen: Are you able to follow up with the feedback you left, to see if the current version addresses it?
David: It looks like he filed a bunch of issues from our feedback and those issues are resolved; i need to look at the issue resolutions to see
Rossen: he did a good job of linking to the PRs that addressed each one.
... [gives example]
Tess: push this out a week or two?
David: Sure
[pushed out one week]
[rossen drops
2020-04-13
David: comment from dlibby - said will work on addressing points.
Rossen: all of the edits are in - all addressed in WICG in terms of PRs. As far as the authors understand it, the ball is in our court.
David: Ok - i will do this and let's bump till next week.
bumpe
2020-04-20
Rossen: David still has some open questions in the issue
David: but he did miss the points about diameter and what units it is in. Also Web IDL errors.
Ken not a big fan of them doing prematurely extensibility - added comment to the issue.
David: Fine with closing, no strong opinions.
Rossen: Same - but too close to the issue to make the call.
Ken: Let's defer to the plenary
OpenedFeb 14, 2020
Hello TAG!
I'm requesting a TAG review of Delegated Ink Trail
Achieving low latency is critical for delivering great inking experiences on the Web. Today, ink is generally produced by consuming PointerEvents and rendering strokes to the application view, but this introduces a good bit of latency by itself. The goal of this enhancement is to reduce this latency as much as possible, by providing a compact API that can add a few extra points to the end of the ink stroke that has already been rendered. This will be achieved by forwarding input directly to the display compositor. Then just before the back buffer is presented any points that haven’t already been rendered by the application can be applied and connected to the stroke already rendered. This, combined with potentially predicting a point or two ahead, can reduce perceived latency and provide a progressive enhancement over other latency improvements.
Further details:
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @mabian-ms