On the other hand native toolkits have had hardware-accelerated text rendering for years if not decades. Browsers are not actually good at being a UI toolkit. They are good at handling a variety of inputs of a variety of questionable quality with a variety of usage patterns. They are good at being very defensive in the face of arbitrary inputs. They are a great catch-all, but as a result they are never actually fast at anything in particular.
No doubt there's good reasons for the slow browser performance (like text as you mentioned, layout, event management, etc.) ... but it's still kinda crazy that with the power of computers today, tearing down and building up a tree that results in calculations for no more than a few thousand sprites or so is a performance killer.
Would be nice if I could just re-render the entire DOM every tick. I've been playing with doing exactly that via lit-html and it seems to be working fine... but still, the idea is "the dom is sensitive - don't change what you don't need to" :\
Yes, and this is why non-Latin text in many games is at best a texture, and at worst, horribly, incorrectly rendered.
The state of the art for Arabic in Unity is I believe a plugin that basically does manual shaping by replacing code points. There may be a Harfbuzz plugin, idk.
Though that was with the old vector/cpu Flash, not the Starling/gpu stuff.
(also a question to the siblings here! I'm not totally clear on HN etiquette when one wants a "reply all"...)
Canvas has the same problem, though there are tricks like compiling Harfbuzz to wasm to get around that. There are proposals for a Web Shaping API to expose the underlying shaping engine used by the browser.
(I don't know if there a writeup somewhere about this other than scattered information in the mozillagfx newsletter and issue trackers?)