Hacker News new | past | comments | ask | show | jobs | submit login

Good point and thanks for the link! However, doesn't it imply that text rendering is a bottleneck anywhere - games, digital signage, etc.?

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" :\

> Good point and thanks for the link! However, doesn't it imply that text rendering is a bottleneck anywhere - games, digital signage, etc.?

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.

By the way - kindof a tangent, but if we're mentioning Unity I remember with Flash around ~8 years ago using TLFText. Seemed really good iirc.

Though that was with the old vector/cpu Flash, not the Starling/gpu stuff.

Interesting. So does all text in the browser go through the same problem space? Canvas, SVG, and HTML?

(also a question to the siblings here! I'm not totally clear on HN etiquette when one wants a "reply all"...)

SVG and HTML use the browser's text rendering stack, which is pretty good. (Native UI elements also benefit from native rendering stacks).

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.


Servo / WebRender originally this idea - they started with this philosophy but ended up adding a lot of caching of draw results, swinging the pendulum back somewhat.

(I don't know if there a writeup somewhere about this other than scattered information in the mozillagfx newsletter and issue trackers?)

This is complicated, but the short answer is that it motivates actual incremental approaches, as opposed to rebuilding the world from scratch all the time. Imgui works best when the rendering is fast, which can be the case when the GPU is doing almost all of the work.

Oh, I see - although this is a relatively old issue on the imgui repo, seems like it's the bottom line (and expresses the same ideas mentioned here): https://github.com/ocornut/imgui/issues/1228#issuecomment-31...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact