Expose an internal API that will let us plug in a separate render stack

[Tyriar]

Parent issue: #221145

The initial plan with the webgpu based is to provide a separate mode via a setting (editor.gpuAcceleration: 'on' | 'off'?) which will switch the rendering stack to a GPU-based one. The first step is for this renderer to simply fallback entirely to rendering lines using the DOM such that we can start self hosting on it and then incrementally swap out parts to render onto a canvas.

Some requirements:

• The new renderer will need to create a canvas that sits below all the editor content, is sized to the viewport (excluding minimap/breadcrumbs) and has a fixed position (since moving it would cause a layout).
• Initially this could cover just the editor viewport (.view-lines). Eventually we want to swap out the line numbers as well (.margin-view-overlays .line-numbers) since they're relatively expensive, ideally we would share the canvas for this.
• We want to be able to incrementally swap out view parts of monaco as they are implemented on the GPU side, for example rulers would be an easy win.
• The more we can isolate the GPU code the better as this feature will be experimental and opt-in for some time and we don't want to leak the complexity of dealing with webgpu to the rest of the codebase.

You can look at the parts outside of the gpu/ in tyriar/gpu_exploration for the parts that I needed to hook into to get it to work. Note that disableNonGpuRendering can mostly be ignored initially, this was used get a better idea of the kind of numbers if we could theoretically get by removing almost all DOM interaction.

VisibleLinesCollection owned the canvas and renderer:

vscode/src/vs/editor/browser/view/viewLayer.ts

Line 262 in 4f7eede

private readonly _canvas: HTMLCanvasElement;

vscode/src/vs/editor/browser/view/viewLayer.ts

Line 362 in 4f7eede

private _gpuRenderer: GpuViewLayerRenderer<T> | undefined;

VisibleLinesCollection disabled ViewLayerRenderer being created (would be needed for fallback?):

vscode/src/vs/editor/browser/view/viewLayer.ts

Lines 368 to 370 in 4f7eede

	if (viewOverlays) {
	renderer = new ViewLayerRenderer<T>(this.domNode.domNode, this._host, viewportData);
	} else {

Forcing the DOM node to not shift around was done in ViewLines:

vscode/src/vs/editor/browser/viewParts/lines/viewLines.ts

Lines 613 to 614 in 4f7eede

	this.domNode.setWidth(this._context.viewLayout.getCurrentViewport().width);
	this.domNode.setHeight(Math.min(this._context.viewLayout.getCurrentViewport().height, 1000000));

vscode/src/vs/editor/browser/viewParts/lines/viewLines.ts

Lines 667 to 671 in 4f7eede

	// (3) handle scrolling
	this._linesContent.setLayerHinting(this._canUseLayerHinting);
	this._linesContent.setContain('strict');
	// this._linesContent.setTop(-adjustedScrollTop);
	// this._linesContent.setLeft(-this._context.viewLayout.getCurrentScrollLeft());

[Tyriar]

Another approach that might work better is to allow view parts to optionally draw to a canvas. For example:

• viewLayer.ts/view.ts or something similar manages the shared canvas and renderer object
• viewParts/lines/gpu/ contains the logic to render to a canvas
• viewParts/lines/ contains something that determines whether to draw via dom or gpu
• We could then use the pattern for all view parts (viewParts/<part>/gpu)

I'm not sure about the persistence of object in viewParts/ but as long as we have a shared renderer object we would be able to set/fetch state on that if needed.