Fastest way to update/render text

1

Suppose we limit ourselves to DOM nodes (i.e. no WebGL / WebGPU), what is the fastest way to render colored text ?

If there was no coloring, I'd just have a giant <pre>...</pre> element and stuff all the text there. However, given foreground/background colors, it seems we can't use one big <pre>...</pre> element and have to use div's.

Div's however would have the problem of reflow-ing on updates. So we would have to use Div + css for absolute positioning and manually calculate the locations of the text.

Is this the optimal way, or is there something better? (Another crazy idea is to use canvas and redraw the entire text scene on every frame, but I am not sure if that is fast enough).

2

It sounds a lot like what the abandoned Atom text editor did. Originally it used React to render syntax highlighted text, and that was replaced in 2015 by plain old DOM updates (citing performance concerns). They fully rewrote it again in 2017 leveraging newer DOM APIs to make the "rendering faster". In 2018, the project wanted to replace the DOM entirely with WebGL, again citing performance concerns.

Since Atom's demise in 2022, part of the team responsible for it founded Zed Industries to continue development on the core ideas behind the editor. As of last March, their blog describes how the most recent incarnation is ... Leveraging Rust and the GPU to render user interfaces at 120 FPS (zed.dev)

VS Code is still using the DOM for its text editor component (monaco-editor) and they have experimented with replacing it with WebGL: Explore GPU rendering in the editor · Issue #162445 · microsoft/vscode (github.com). Claiming in part:

  • There are big wins to FPS/scrolling performance and overall smoothness of the application, especially for average/old hardware.

There is a theme here, but I'll leave it at that. If the DOM is a hard constraint, you are going to have a problem.

I agree that using the canvas context 2D API is not a good idea. One of my largest contributions to an open source HTML game engine was replacing the canvas 2D renderer with WebGL 1.0 (this was in 2015) because it was a decent performance boost (1.6x faster with naive benchmarks on the initial implementation) and battery saver on mobile devices.

2 Likes
3

  1. Thank you for the well researched response. The historical aspect (benchmarks / discussions) from Atom github issues is really insightful.

  2. Is Zed open source? They have a github repo, but it's just community / docs -- not seeing the actual code.

  3. The TLDR is: everything is shifting towards WebGL2 ? The most "complete" Rust/WebGL2 UI I've found so far is GitHub - makepad/makepad: Makepad is a creative software development platform for Rust that compiles to wasm/webGL, osx/metal, windows/dx11 linux/opengl but it tends to be monolithic and not easily to integrate with others.

4

There's another blog post on zed.dev where they discuss their plans for open sourcing the project.

WebGL2 is already like 6 years old. And because it's based on GLES 3 it inherits all of its overhead. WebGPU wants to bring the low-overhead benefits of Vulkan to web tech and it has been in development for many years already. That's where the current heading is pointed.

But the short answer is "yes, everyone is moving their UIs to the GPU for a variety of reasons."

There are plenty of UIs written in Rust with a WebGL backend. I can name a few off the top of my head:

1 Like
5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.