remote: add canvas desynchronized option

[peterpeterparker]

Description

Mentioned by @jgw96 in his last article, canvas now supports a desynchronized option. We could add this option to the canvas used by DeckDeckGo to improve performance too.

Code

This implementation should find place in the remote component and app

[grantlouisherman]

Hey @peterpeterparker can I take a look at this?

[peterpeterparker]

@grantlouisherman sure, that would be awesome!

but before implementation, could you double check if this would improve or not our canvas?

I remember I read the article and learned about it but it is worth to control before investing time 😉

Thx

[grantlouisherman]

Hey @peterpeterparker so I have done a little bit of research. These two articles are probably the best: https://developers.google.com/web/updates/2019/05/desynchronized, https://www.chromestatus.com/feature/6360971442388992. Here is a presentation on rendering: https://docs.google.com/presentation/d/1boPxbgNrTU0ddsc144rcXayGA_WF53k96imRH8Mp34Y/edit#slide=id.g60f92a5151_40_102

Here is a code pen you can plan with: https://codepen.io/miguelao/pen/ZjJNNw

I think overall it really matters if you think people are using stylus drawing a large amount because drawing on the web seemed the exact same( see Codepen). It's a little convoluted to me, but essentially it seems like when you desynchronize it is bypassing the normal queue for drawing events and is directly tapping into GPU. I don't really understand the drawbacks, but I'm assuming there might be wonky things that happen if you are bypassing the queue of drawing events. One issue they bring up is flickering, which I think is a weird flicker of the image on the canvas. We can implement it in the Component and see what it looks like. I, however, don't have a stylus so I might not be the right person for this ticket. So I might drop this and look for something different to do.

[peterpeterparker]

thank you very much @grantlouisherman for the analysis!

I'm agree with, it seems that this option isn't that needed for our components, as it has an effect on the latency interaction.

Also it seems needed when there are a lot of data, which might not be our case.

On the other hand, not in the components but in the "remote control", the users do have the ability to draw over the presentation.

Not a must, rather a NTH, but still, maybe it's something we could implement there (in the "remote") respectively at the following line of code:

deckdeckgo/remote/src/app/components/app-draw/app-draw.tsx

Line 137 in 6cfa2e2

this.ctx = canvas.getContext("2d");

[grantlouisherman]

Hey, @peterpeterparker I can create a branch. Do you have a stylus to test the drawing?

[peterpeterparker]

We could ask Nicolas (@nmattia) to give a try (if I deploy something), he has got a stylus for his iPad

[nmattia]

Can do!

[grantlouisherman]

hey @nmattia @peterpeterparker here is the branch https://github.com/grantlouisherman/deckdeckgo/tree/feat/issue-437-canvas

When testing with the stylus let me know how it looks. I might need to add https://developers.google.com/web/updates/2019/05/desynchronized#avoiding_flicker depending on how the drawing manifests. I looked at the code and I don't think this should be an issue, but you never know.

[peterpeterparker]

thx @grantlouisherman !

I've deployed a test version and pinged @nmattia

We keep you posted

[peterpeterparker]

@grantlouisherman Nicolas did some testing and our conclusion were that is was actually "same same". as you mentioned, the flag improves the performance for large amount of data, I guess at least in the case of our test, if wasn't the case, therefore we don't notice anything specially.

even if there isn't much change yet, I would say, we merge the improvement if you could provide a PR?

We never know what we gonna add in the future or what will change, as it is already developed, I would say let's go for it 😉