Vscode: Lists in views are no longer on a separate GPU layer

Created on 11 May 2020  路  9Comments  路  Source: microsoft/vscode

Right now when scrolling project explorer vscode redraws entire window (as can be seen on mac by enabling "Flash screen updates" in Quarz Explorer. This can be rather sluggish on HiDPI screens.

This does not happen when scrolling code editors, as they are using separate layers (triggered using translate:transform3d(0,0,0)) i believe.

Same should be done for panes. The scrolling performance is much better when adding something like "div.pane { translate:transform3d(0,0,0); } or contain:strict.

The only problem I encounter is that newly scrolled items are painted without subpixel antialiasing. I don't know the reason why this happens, but I assume it should be fixable since subpixel aa is working for the main editor.

candidate important list regression verified

Most helpful comment

@knopp excellent analysis btw, kudos. Great catch 馃憤

All 9 comments

/cc @bpasero @deepak1556

The only problem I encounter is that newly scrolled items are painted without subpixel antialiasing.

Well, that would be a blocker because we heavily invested in supporting subpixel-AA everywhere.

Though I thought the tree/list was different, but I forgot, maybe we removed this. @joaomoreno what is the latest of the list widget using the scroll trick from the editor?

Well, that would be a blocker because we heavily invested in supporting subpixel-AA everywhere.

I agree. However given that it works in main editor, perhaps there is a way to determine what exactly is causing chromium to drop subpixel aa for new items and work around it.

The speed improvements when scrolling through a large project on 4K HiDPI screen are pretty significant.

I don't think the initial premise true:

recording (4)

Every list, tree and editor is already in its own layer. The lists and trees are currently doing the same as the editors.

Can you use the Paint Flashing tool from the built-in DevTools?

@joaomoreno, this may be actually Mac specific. It is about how Chromium split the scene in CALayers and which CALayers get updated. There is no easy way on Mac to do partial damage update, so instead Chromium splits the scene in multiple CALayers that can be individually updated.

You can then use Quartz Debug (from additional Xcode tools) and enable "Flash screen updates" to see which part of windows are updated. You can also run vscode with "--show-mac-overlay-borders" to see how the scene is split into multiple CALayers.

And here is where it gets interesting. I actually found just now that this is a regression between 1.45 and 1.44.2. I'm attaching screenshots with -show-mac-overlay-borders. You can see that in 1.44.2 there is a layer border around the explorer, which is not present in 1.45. Thus scrolling explorer refreshes the entire window. I replaced electron from 1.45 inside 1.44.2 and it still works properly, so it looks like vscode regression instead of electron one.

borders - 1 44 2borders - 1 45

Okay, so the regression is that in 1.45, div.monaco-list-rows no longer has transform:translate3d(0px, 0px, 0px)

@rebornix @sbatten this probably qualifies as candidate. it looks like options.transformOptimization was added which maybe you forgot to pass in for lists?

@knopp excellent analysis btw, kudos. Great catch 馃憤

Was this page helpful?
0 / 5 - 0 ratings