Webview rendering lagging

[rebornix]

Originally reported by @kieferrm with the notebook exploration: when scrolling a notebook whose outputs are rendered inside a webview, the webview doesn't scroll at the same speed as the notebook list view.

Note: you may need to test this with MacBook Pro's touchpad to get the same result

As shown in above gif, the editor is rendered in the core and the html form is rendered in a webview, while scrolling in the core, the gap between the editor and the form shifts from 30px to ~34px and finally end up with 32px when the scrolling ends.

What happens under the hood is, the list view in the core receives onscroll event, sends scroll top change change event to the webview. Inside the webview, the form will be repositioned. And then the list view will scroll itself.

This used to work smoother than what we saw above. Based on my testing and compassion, Electron 6 is better than Electron 7. I labeled this issue as electron-7-update for this reason.

I explored a ton of approaches to reduce unnecessary position changes in the list view, send scroll events to the webview as early as possible. None of them worked consistently, I mean they sometimes worked great, but sometimes they don't.

Luckily I found two ways to consistently improve the lagging but they are hacks

Devtools

As long as I have Devtools open, the lagging between the scrolling in the core and the webview I ways less noticeable. My suspicious is the rendering of the core is slower so it becomes as slow as the webview, thus no noticeable lagging.

Trigger scrolling from the webview

When we scroll the wheel in the webview, we will emit the wheel event to the core. Once the core receives the wheel event, it will then treat it as a native wheel event: scroll the list view and tell the webview to scroll the HTML form inside. The lagging is near 0 (visually)

---

This made me think that the webview might have a lower priority when users are interacting with the renderer so it will leads to lagging when we try to sync their scrolling positions. If users are interacting the webview, then they kind of have the same priority.

@deepak1556 I'd love to have your expertise on this topic and see how we can improve the experience, apparently the webview can scroll almost at the same time as the core but we need to figure out how to do that stably. We should also try iframe and see if it helps with the lagging too.

[rebornix]

Some more info about the different between scrolling in the main ui and scrolling in the webview:

scrolling in the main ui

Scroll event handler first, and then Layout, Update Layer Tree

scrolling in the webview

Layout and Update Layer Tree first, and then scroll event handler.

[rebornix]

@deepak1556 guided me to the perfect solution (perfect means perfect for the coming 12 months at least):

Previously the webview in the back layer has the same height as the editor, the content inside has a container which works similarly to the list view container, it is absolutely positioned and has a top. When we scroll the list view, the top of the list view container changes, we send events into the webview, and change top of the container in the webview accordingly.

Now what we are going to do is the webview will has the same scrollHeight as the list view. It means it will be way larger than the real height of the editor, but according to @deepak1556 and what we tested, the height itself doesn't affect the performance noticeably. And then when the list view scrolls, we just change the webview's position without sending messages into the webview.

[rebornix]

Fixed via a03546f