Editor: Interaction triggering drastic browser repaint

[ItsJonQ]

Describe the bug

I've noticed some lagginess with my local development. At first, I thought it may have been my computer. I did some testing, and it looks like there's some serious repainting happening in the editor - specifically from typing and scrolling.

I've recorded a video demo:
https://d.pr/v/NeLmSy

Every letter I type or every pixel I scroll triggers the entire page to redraw.

This can be tested by...

• Opening Gutenberg with Chrome
• Opening Chrome Developer Tools
• Press Esc to show extra panel
• Click on "Rendering"
• Toggle "Paint Flashing"

Editor version (please complete the following information):

• Latest Gutenberg master

Desktop (please complete the following information):

• Mac OS
• Chrome, Version 83.0.4103.106

[alexvornoffice]

Yeah it is laggy for me too, I think this is by design to redraw everytime you time something...

[ellatrix]

Hm, when I type, I only see the flashing inside the paragraph

[ItsJonQ]

@ellatrix Hmm! Strange.. The entire screen flashes for me. It happens for both TwentyTwenty and TwentyNineteen themes.

I do think I've figured out something for scrolling (and some overall flashing)
https://d.pr/v/R1ZKxp

It's a combination of adjusting the .interface body/sidebar layers (via translate3d) , and changing the Popover.Slot layer.

Note: I'm not saying the suggestions above are the best solutions! I'm sure adjust Popover things is quite risky. Just sharing what I've found so far :)

[ItsJonQ]

Interesting update!! My investigation is leading me to believe that maybe it's something keyboard event related. Maybe.

Check this out:
https://d.pr/v/SjQJIV

In the above video... I've added a random <textarea /> to the Paragraph block edit. It's not connected to @wordpress/data. It's not using useState or anything. However, on every keystroke, the entire window repaints.

On top of that. Spamming keys into the <textarea /> causes lag. (This is the strangest part).

A simple non-connected component shouldn't lag when typing 🤔

[alexvornoffice]

Can you please tell how to highlight the element like you do? I am using Chrome...

[ItsJonQ]

@alexvornoffice Oh sure thing! I recorded a quick screencast walkthough. Hope this helps!

https://d.pr/v/uAhLyG

[ItsJonQ]

Continuing my poking... It looks like removing overflow: auto from .interface-interface-skeleton__body fixes the entire view re-painting on keystroke. Of course this breaks the internal editor scrolling (haha).

I don't think removing overflow: auto is the solution. Just sharing for debugging/investigation purposes!

[ItsJonQ]

Updates! Ah ha!!! I think I may know what's happening.

The various scrollable areas (most notably body and sidebar) are using a combination of flex, height: 100%, and overflow: auto to determine whether a scrollbar needs to render.

However, since none of these values are really "fixed" (e.g. height: 100vh or height: 802px), then the browser appears to have to do a layout calculation for every DOM mutation (e.g. typing a character).

I may have a work around for this. Stay tuned!

[corentin-gautier]

As @ItsJonQ found out, the overflow: auto; triggers a lot of repaint both when typing but also every time a popover is added to the DOM. Here's a video of the issue :

Screen.Recording.2022-12-05.at.14.21.43.mov

When changing overflow: auto; to overflow: auto scroll;

Screen.Recording.2022-12-05.at.14.22.39.mov