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