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

[Tyriar]

Parent issue: https://github.com/microsoft/vscode/issues/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:

https://github.com/microsoft/vscode/blob/4f7eededdcbaadc8f9e1bc52c72188aa906684c2/src/vs/editor/browser/view/viewLayer.ts#L262 https://github.com/microsoft/vscode/blob/4f7eededdcbaadc8f9e1bc52c72188aa906684c2/src/vs/editor/browser/view/viewLayer.ts#L362

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

https://github.com/microsoft/vscode/blob/4f7eededdcbaadc8f9e1bc52c72188aa906684c2/src/vs/editor/browser/view/viewLayer.ts#L368-L370

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

https://github.com/microsoft/vscode/blob/4f7eededdcbaadc8f9e1bc52c72188aa906684c2/src/vs/editor/browser/viewParts/lines/viewLines.ts#L613-L614 https://github.com/microsoft/vscode/blob/4f7eededdcbaadc8f9e1bc52c72188aa906684c2/src/vs/editor/browser/viewParts/lines/viewLines.ts#L667-L671

[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.