> Rendering a GUI can be done in real time on ancient CPUs.

That depends on the style of GUI. As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful.

> As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful.

Didn’t Windows XP (and prior) not render the window as it was dragged, but just a dashed box? And when you release the window, it’d be redrawn in the new spot.

I believe Windows 95 had only that behavior… but everything after it could render in real time.

In Windows 98, it's under the Control Panel → Display → Effects → Show window contents while dragging

https://copy.sh/v86/?profile=windows98

(The VM here is slower than a machine of the era.)

(I also want to say Transport Tycoon Deluxe's windows were draggable without needing a frame / in real time, and that was in DOS?)

XP rendered the window unless you had a few settings switched (or the classic theme on).

In fact, dragging a window in XP was the quickest way to see if hardware acceleration was properly enabled.

If you saw the window tearing while being dragged, chances were installing an extra driver would make the user a lot happier.

Haiku does some amazingly impressive things software-only, drag & drop and scroll really don't need hardware acceleration. If they do, there's a problem with your code.

Mind you, I can do real-time 1080p mp4 video scrubbing on haiku running on a thin client so...

I was thinking about it and the issue is really the "if there's no compatible hardware llvmpipe will just take care of it" attitude. If you watch these software rendered graphics carefully (or read the code) they make trade-offs that allow everything to work with low input latency and render in real time and sometimes that means "corrupt" looking graphics on the screen which the OpenGL style graphics won't generate (the frame is either done or it gets skipped.)

It's certainly useful but it tends to break and in the context of embedded: constrain hardware choices to vendors known to have serious support problems.

CPUs are more than capable of rendering graphics needed for gestures like you mentioned.

>IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers.

This has been my experience too with an old GMA GPU, I have to keep disabling hardware acceleration in everything I try to run (browsers, electron apps if possible, desktop environments). The UI runs order of magnitude faster on the CPU than on the GPU through OpenGL.

I don't think these anachronistic comparisons make any sense. GMA might do OGL2.1 at best, it won't work well with software with modern assumptions. I wouldn't be surprised if it doesn't use GPU at all and falls back to software OGL renderer.

It tries to do hardware rendering, I had to force software rendering due to artifacts and messed up colors in addition to slow rendering.

Sure and ImGUIs are extremely unpleasant to use in power/resource constrained environments.

You should look at GTK+, motif, or TCL/Tk. They're very straightforward and don't turn people's devices into hand warmers.

GTK in resource constrained environment? Uh...

Motif, along with X11 is just completely obsolete platform. (btw, this is what UHH thinks about it: "What Motif does is make Unix slow. Real slow.")

There's some weird GPU hate in this thread that I don't quite understand. Try to render dragging content of 1080p window at 60fps on cheap mobile ARM core, and you will likely blow your whole time budget just on filling the window with solid color...

Like on the PinePhone, using sxmo? Works great.

Ditching the _enormous_ Android stack is an easy win.

That was Brillo's main goal, except when it came to production it got rebooted as Android Things and now is dead.

Is this because they tend to heat up when you use a GL context? And the UI toolkits composite to the screen less often?

I'm not a mobile developer so this is all new to me. Thanks for the info.