[PR #126] perf: promote canvas containers to GPU compositor layer #130

New issue

Open

opened 2026-05-06 13:13:31 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 13:13:31 +02:00

Owner

📋 Pull Request Information

Original PR: https://github.com/bwya77/vscode-dark-islands/pull/126
Author: @McSon2
Created: 5/3/2026
Status: 🔄 Open

Base: main ← Head: perf/gpu-layer-promotion

📝 Commits (1)

c6a6541 perf: promote canvas containers to GPU compositor layer

📊 Changes

1 file changed (+25 additions, -6 deletions)

View changed files

📝 settings.json (+25 -6)

📄 Description

Summary

The border-radius: var(--islands-panel-radius) !important; overflow: hidden !important; combo on .part.editor and .part.panel.bottom causes noticeable lag in the editor and terminal on slower machines. Every time the Monaco editor canvas or the xterm canvas redraws (which is constantly during typing/scrolling), the rasterizer has to re-clip the canvas to the rounded shape on the CPU compositing path, because the rounded clip lives on a non-promoted layer.

This PR forces those containers onto their own GPU compositor layer so the rounded clip is applied once per frame at composite time, on the GPU, instead of being recomputed every time the canvas redraws.

The fix adds four properties to the canvas containers:

Property	Why
`isolation: isolate`	Creates a new stacking context so `transform` doesn't escape and z-index ordering stays predictable
`transform: translateZ(0)`	The classic GPU layer-promotion trigger; makes Chromium allocate a separate composited layer
`will-change: transform`	Hints to the engine that this element should be optimized for compositing
`contain: paint`	Tells the engine that painting is contained within the element's box, allowing further compositor optimizations

Affected selectors:

.part.editor
.part.panel.bottom
.part.panel.bottom > .content
.part.panel.bottom .terminal-outer-container
.part.panel.bottom .terminal.xterm
.notebookOverlay

Visual change

None. The rounded corners, glass borders, shadows and overall look are identical — this is purely a rendering-pipeline optimization.

Test plan

Verify settings.json is still valid JSON
Apply on a real Cursor install (3.1.17 / macOS 15) with a heavy workload (5+ tabs, integrated terminal running npm run dev, Monaco at scroll) and confirm typing latency / terminal redraw is back to baseline
Confirm no visual regression on VS Code (untested by submitter — would appreciate a check on a vanilla VS Code install)
Confirm no regression on the Linux selectors (.monaco-workbench.linux .part.editor > .content is untouched but the layer promotion on .part.editor could interact with it)

Notes

The same border-radius + overflow:hidden pattern exists on the sidebar (.part.sidebar, .part.auxiliarybar) but those don't lag, because their content is regular DOM rather than <canvas> — DOM clipping in rounded corners is essentially free, canvas clipping is not. So I deliberately did not add the GPU promotion there: it would create extra compositor layers for no gain.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/bwya77/vscode-dark-islands/pull/126 **Author:** [@McSon2](https://github.com/McSon2) **Created:** 5/3/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `perf/gpu-layer-promotion` --- ### 📝 Commits (1) - [`c6a6541`](https://github.com/bwya77/vscode-dark-islands/commit/c6a65419827aa47752eb16177710c4fb7da9c00f) perf: promote canvas containers to GPU compositor layer ### 📊 Changes **1 file changed** (+25 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `settings.json` (+25 -6) </details> ### 📄 Description ## Summary The `border-radius: var(--islands-panel-radius) !important; overflow: hidden !important;` combo on `.part.editor` and `.part.panel.bottom` causes noticeable lag in the editor and terminal on slower machines. Every time the Monaco editor canvas or the xterm canvas redraws (which is constantly during typing/scrolling), the rasterizer has to re-clip the canvas to the rounded shape on the **CPU compositing path**, because the rounded clip lives on a non-promoted layer. This PR forces those containers onto their own **GPU compositor layer** so the rounded clip is applied once per frame at composite time, on the GPU, instead of being recomputed every time the canvas redraws. The fix adds four properties to the canvas containers: | Property | Why | |---|---| | `isolation: isolate` | Creates a new stacking context so `transform` doesn't escape and z-index ordering stays predictable | | `transform: translateZ(0)` | The classic GPU layer-promotion trigger; makes Chromium allocate a separate composited layer | | `will-change: transform` | Hints to the engine that this element should be optimized for compositing | | `contain: paint` | Tells the engine that painting is contained within the element's box, allowing further compositor optimizations | Affected selectors: - `.part.editor` - `.part.panel.bottom` - `.part.panel.bottom > .content` - `.part.panel.bottom .terminal-outer-container` - `.part.panel.bottom .terminal.xterm` - `.notebookOverlay` ## Visual change None. The rounded corners, glass borders, shadows and overall look are identical — this is purely a rendering-pipeline optimization. ## Test plan - [x] Verify `settings.json` is still valid JSON - [x] Apply on a real Cursor install (3.1.17 / macOS 15) with a heavy workload (5+ tabs, integrated terminal running `npm run dev`, Monaco at scroll) and confirm typing latency / terminal redraw is back to baseline - [ ] Confirm no visual regression on VS Code (untested by submitter — would appreciate a check on a vanilla VS Code install) - [ ] Confirm no regression on the Linux selectors (`.monaco-workbench.linux .part.editor > .content` is untouched but the layer promotion on `.part.editor` could interact with it) ## Notes The same `border-radius + overflow:hidden` pattern exists on the sidebar (`.part.sidebar`, `.part.auxiliarybar`) but those don't lag, because their content is regular DOM rather than `<canvas>` — DOM clipping in rounded corners is essentially free, canvas clipping is not. So I deliberately did not add the GPU promotion there: it would create extra compositor layers for no gain. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>