111–120 of 137 posts
Earlier quoted context omitted.
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
Earlier quoted context omitted.
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.
The perf issues are mainly latency (CPUGPU 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
Earlier quoted context omitted.
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. Ot…
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.
Wait what?? Can someone fill me in? Why would they have different hardware? Compute is compute, even if the computer is mostly good at triangles.
Earlier quoted context omitted.
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. Ot…
> 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 co…
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.
Earlier quoted context omitted.
> 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 co…
> 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 suppor…
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.
So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.
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.
Earlier quoted context omitted.
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.
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…
For those looking for a complete 3D engine already supporting WebGPU and with a WebGL fallback if needed, there is BabylonJs (you'll need the 5.0 version still in the release candidate state) : https://doc.babylonjs.com/advanced_topics/webGPU/webGPUStatu... ThreeJs is alwo working on its WebGPU renderer
For any developers interested, our team at Wonder Interactive is working on WebGPU support for Unreal Engine 4 and Unreal Engine 5. Games and real-time 3D applications in the browser will form the basis of the open metaverse. You can register here on our website for early access - https://theimmersiveweb.com/