[zozbot234]

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

[colejohnson66]

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

[deathanatos]

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?)

[caslon]

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

[unilynx]

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.

[slackfan]

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

[swiley]

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

[swiley]

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.

[rjsw]

The Macintosh did drag-and-drop with no hardware acceleration in 1984.