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

So... semi-serious question, what does html/css give us that imgui doesn't? e.g. taking this idea in another direction - why not just replace the dom hierarchy with a single webgl node and compile imgui to wasm in order to drive it that way?





Browsers have a lot of features we'd need to reinvent. You lose all tooling, all programmability, hyperlink functionality, accessibility, etc. The list goes on and on.

Text rendering is extremely difficult. Even today, Chrome/Firefox are not fully hardware accelerated on this front.

https://gankra.github.io/blah/text-hates-you/


> Text rendering is extremely difficult. Even today, Chrome/Firefox are not fully hardware accelerated on this front.

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.


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.


Thanks!

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

Accessibility is a big issue; I'm unsure if imgui has support for that or if it will work with the browsers built-in support for that.

Does imgui re-render everything every frame or does it do a "diff and patch" technique as well?

With imGui you must fully describe your interface at each frame. Because it's fully GPU accelerated it does not cost that much and run very fluently at 60 FPS.

> it does not cost that much and run very fluently at 60 FPS

But it drains your battery like crazy. Immediate mode GUIs are good for games, which already render the whole scene @60FPS and are expected to be costly, but re-rendering your whole window every frame even when idling is just a waste of power.


The rendering is on the GPU but the description of the UI is created and executed on the CPU, and then the results are sent to the GPU, is that right? In other words, it works a little like a video game.

Yes, you describe your UI from the CPU code and it gets accumulated into a draw list. Differents backends (OpenGL, Direct X, Metal ...) sends them to the GPU for display. It's close to what a game is doing.



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

Search: