Comment by wolframhempel | Hacker News Reader

Comment by wolframhempel | Hacker News Reader

Having built a few GPU/HTML hybrids in the past, (e.g. https://arcentry.com/) I found that it teaches you a lot about the things you take for granted when developing for browsers and that you now have to manage yourself. This includes for example:

- figuring out when to redraw the screen or sections of it

- organizing your UI as a hierarchical tree that can be traversed

- handling events in general. what did the user click on? What Z order are things in? Can we find out using 2D boxes or do we need to do 3D ray intersection?

- combining UI hierarchies and events into event propagation

- rendering text and images crisply is surprisingly tricky

- blending layers over each other requires care.

- layout flows (margins, paddings, things pushing against other things) need managing.

...and a host of other things. For anyone interested, I wrote a summary in my early days of development here: https://medium.com/@WolframHempel_82303/seven-things-ive-lea... - though this misses a lot of what I figured out later.

With some exceptions, the Qt Graphics View Framework satisfies all these goals with very little additional code from the user.

It won't automatically render things as a tree (but the widget system does that for you) or doing layout flow (it's not a layout manager). But it does all the other things so well it's amazing it hasn't been cloned into every other graphics framework.

https://doc.qt.io/qt-6/graphicsview.html

> figuring out when to redraw (...) sections of it

What happens if you just brute-force and re-render everything when there's a change? I'm all for optimizing but is this really required these days? Even considering laptops and mobile power requirements, rendering off-screen and flipping is lightning fast.

Layout flows are a different matter and can be expensive to compute.

> Even considering laptops and mobile power requirements, rendering off-screen and flipping is lightning fast

I believe it is not speed, but battery life. Most of the time nothing happens on the screen besides some small widget changing like once per second (e.g. clock), doing 59 full rerenders every second for that (or even more with high refresh rate screens) is significantly higher drain.

But I am absolutely not an expert on this.

I think that's right. I started of just rendering everything on every requestAnimationFrame callback - and things rendered smoothly, especially when nothing needed copying to the GPU. But users complained that their laptop fans sprang into action and their battery life plummeted.

Your point is correct and there is another changing thing beyond the clock that's common - the blinking caret in a textbox. Firefox used to have really bad battery usage on macOS for a long time because in order to only change the caret you have to do a lot of things the Apple way.

Oh didn’t think of that! When you are more in control of the hardware then hardware planes could help with that - at least cursors in display managers are handled that way.

Does native OS frameworks have some escape hatch for these slightly changing, constantly damaging elements?

> I'm all for optimizing but is this really required these days?

Of course it is. Even if it doesn't matter on your machine, your users will launch your code:

* on a 10 years old PC

* in train on a laptop with 10% battery left

* on a computer with so many things running in the background that you'll be on the edge of thrashing

* on a thermally throttled ultrabook

* on an underpowered SBC

* through foreign CPU arch emulation

* [insert more cases here]

In each of those scenarios, your code will either do its job well or be the source of frustration.

    figuring out when to redraw the screen or sections of it

Yes. I did a fun side project where I wrote a client-server protocol and browser for terminal user interfaces and I had to learn all of this. It was a lot of fun though and I learned a lot about browser design and how it manages cookies.

Info here: http://uggly.bytester.net/

Just wanted to say that arcentry's diagrams looked amazing. You did a fantastic job.

Reply on news.ycombinator.com