Re: [w3ctag/design-reviews] Delegated Ink Trail (#473)

Thanks for the great feedback, much appreciated! 

The string parameter to `requestPresenter` is indeed intended to be extensible in the future, but as you pointed out, we didn't explain any of that (whoops). I filed an [issue](https://github.com/WICG/ink-enhancement/issues/5) in the WICG repo (where the explainer has moved since the TAG review request was made) - we do think there could be room for more `InkPresenter`s in the future. The delegated ink trail in the proposal is the simplest form of this, but you could imagine authors wanting similar functionality but with the ability to render the trail with shaders. That being said, it's possible that we're overthinking the extensibility and can start with something more straightfoward.

The request returning a Promise is a side-effect of the design for extensibility. It's possible, e.g., that something like the complex trail would only be supported if hardware rendering is enabled, or some other criteria that is not immediately available.

Good point on the radius type, and also the lack of clarity. I filed an [issue](https://github.com/WICG/ink-enhancement/issues/6) to address this in the explainer. The radius describes the stroke weight at the last application-rendered point so that the UA or OS can match. Inking applications can use pressure to change this value as the user moves the pen in different ways.

I agree the naming could be improved - as it stands there's somewhat of an unspoken/implicit agreement that `setLastRenderedPoint` will result in the ink trail being rendered outside of the application. Filed an [issue](https://github.com/WICG/ink-enhancement/issues/7) to come up with a better name.

The optionality of `presentationArea` is explained in a paragraph that is not clearly marked - the area would default to the viewport. Yes the `presentationArea` attribute would be the argument passed to `requestPresenter`. Filed an [issue](https://github.com/WICG/ink-enhancement/issues/9) to clean this up.

I can add some more details regarding the prediction bit. This comes in to play in the fallback scenarios, where the application doesn't want to (or can't) use this API. Typically applications will either implement their own prediction, or use the fairly recent `PointerEvent.getPredictedEvents()` function to render ink segments past the last received pointer event. The usage here was mainly to highlight that in these fallback cases, the author has the option to use prediction to decrease perceived latency, where if they do use the API, the application _should not_ try prediction, as the user will see the (potentially incorrect) predicted rendering right next to the ink trail, which will be correct since it uses the real input from a later point in time.

I'll work on addressing these points in the explainer over the next week or so and ping this issue when I'm done.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/473#issuecomment-595626494