If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.

I find your ideas intriguing and I wish to subscribe to your newsletter.

More seriously, yes, if you were starting a browser completely from scratch, this would probably be a good approach. There are some subtleties, but probably nothing that couldn't be solved with some elbow grease.

If anyone is seriously interested in exploring this direction, one thing that would be very interesting is a port of piet-gpu to run on top of WebGPU (it's currently running on Vulkan, Metal, and DX12). I've done quite a bit of pre-work to understand what would be involved, but don't personally have the bandwidth to code up the WebGPU port. I would be more than happy to work with somebody who does.

I wouldn't start a browser from scratch, it's too big and compatibility is a never ending quagmire. I think it would be cool to do a new portable app platform with bits and pieces of the web platform like WebGPU, combined with new stuff, kind of like how deno is using web APIs outside the web. Maybe combined with the ideas from the redbean server.

By "work with somebody", do you mean your team at Google is hiring for this, or are you looking for community contributors?

At the moment, I am talking about community contributors. But if you have a credible plan for getting this done and the thing that would hold it back is funding, let's talk.

I have no credible plan and I would need some mentoring before I could even be productive. Sounds like you probably want someone with more relevant experience.

GPUs aren't particularly good at vector graphics rendering especially at smaller sizes. You'd want a CPU emulator of the GPU code and that seems strictly worse than doing it native.

https://sluglibrary.com/ says otherwise

Games aren't a good system performance workload because nobody cares if they scale down, only if they scale up.

Nothing constrains Slug to games. Adobe has licensed it for example.

Eh, that's a good sign for Unicode support but otherwise it's pretty similar. Photoshop and games are both foreground apps, Acrobat less so, but browsers and system UI are closer to utilities you don't want using all your resources.

The perf issues are mainly latency (CPU<>GPU communication) and power (turning the GPU on) on discrete GPUs, integrated/mobile GPUs are better off there but memory use can be a problem.

Other issues:

- skipping the DOM and system font API loses you copy-paste, translation, and screen readers

- subpixel AA and hinting usually get lost, although they're doable

- it just looks weird when your app uses a different font renderer from everyone else, or even from other text in the same window

> skipping the DOM and system font API loses you copy-paste, translation, and screen readers

Browsers implement their own copy/paste, accessibility, and translation. WebGPU being used for rendering affects none of that.

> subpixel AA and hinting usually get lost, although they're doable

Subpixel AA is a technology of the past and a new forward looking browser should not bother supporting it. Tons of complexity and compromises for small gains on bad screens only.

> it just looks weird when your app uses a different font renderer from everyone else, or even from other text in the same window

This can probably be minimized with some effort. To the extent that it can't be identical, web content is so obviously not native already that I think it doesn't matter.

> Browsers implement their own copy/paste, accessibility, and translation. WebGPU being used for rendering affects none of that.

That's why I said skipping the DOM, as in using canvas or WebGPU yourself. Browsers do handle that properly but unfortunately games or game-like apps don't even if they display lots of text.

> Subpixel AA is a technology of the past and a new forward looking browser should not bother supporting it. Tons of complexity and compromises for small gains on bad screens only.

Apple is the only vendor of highres desktop displays, I think? The reason subpixel AA doesn't work on OLEDs is because they're worse (PenTile instead of RGB) not better.

Safari indeed doesn't do subpixel on HiDPI displays, but that leaves hinting and some other text rendering tricks with similar constraints that a naive renderer would forget about.

In the comment you're replying to I did not propose skipping the DOM, I proposed rendering the DOM via WebGPU. As an implementation detail of the browser, not as something websites should do themselves.

Um, Apple is far from the only vendor of high res displays. And not all OLEDs are PenTile. The trend in all displays is to higher resolution where subpixel AA is unnecessary complexity, and especially on mobile which is more important than desktop these days and where nobody ever does subpixel AA, even on relatively low resolution displays that could support it.

> In the comment you're replying to I did not propose skipping the DOM, I proposed rendering the DOM via WebGPU. As an implementation detail of the browser, not as something websites should do themselves.

Hmm, I guess so, but writing the browser based on WebGPU seems limiting? You can use native code there.

> Um, Apple is far from the only vendor of high res displays.

There's stories on here every day about how they are.

https://news.ycombinator.com/item?id=30604375

https://news.ycombinator.com/item?id=30631288

> And not all OLEDs are PenTile.

Meant to say "mobile OLEDs" if you insist. There's no desktop OLEDs, people don't seem to enjoy using RGBW TVs as displays. Couldn't say why.

> There's stories on here every day about how they are.

There's stores about their high res displays, but to the extent they claim Apple is the only vendor that's just plain false.

If I developed a new browser today, my baseline graphics abstraction would be CPU-side pixel buffers manipulated by compiled (WASM/native) code. CPU rendering works equally well on past, present, and future CPUs, works with working and buggy and missing GPU drivers, works on every computer made in the last few decades, will never be obsoleted like Glide and DX7-9 and OpenGL, and is plenty fast enough outside of 4K or 144FPS rendering.

No need to develop a new browser, you can easily configure yours to disable GPU rendering. If you like things to be slow and inefficient. Personally I'm never buying any display under 1440p 120 Hz again and I prefer to run workloads where they're efficient, so I'll continue to use GPUs for graphics.

Doesn't WebGPU require a DX12-level GPU? If so, that would make your browser incompatible with a ton of systems out there.

Writing a new browser would take many years and those systems would be obsolete :) But there's also an intention to produce a more compatible restricted subset of WebGPU at some point.

There's at least five now: DOM, canvas, SVG, webgl, webgpu. Could maybe make an argument that fonts are an entirely separate rendering engine with quirks and issues too. CSS Houdini might even be another new one.

yes