D GUI Framework (responsive grid teaser)

Nick Sabalausky (Abscissa) SeeWebsiteToContactMe at semitwist.com
Thu May 23 20:10:34 UTC 2019

On 5/22/19 8:34 PM, H. S. Teoh wrote:
> And this isn't just for mobile apps; even the pervasive desktop browser
> nowadays seems bent on eating up as much CPU, memory, and disk as
> physically possible -- everybody has their neighbour's dog wants ≥60fps
> hourglass / spinner animations and smooth scrolling, eating up GBs of
> memory, soaking up 99% CPU, and cluttering the disk with caches of
> useless paraphrenelia like spinner animations.
> Such is the result of trying to emulate game-engine-like behaviour.

No, that resource drain is BECAUSE they're trying to do game-like things 
WITHOUT understanding what game engine developers have learned from 
experience about how to do so *efficiently*.

>  And
> now you're recommending that everyone should write code like a game
> engine!

Why is it so difficult for programmers who haven't worked on games to 
understand the basic fundamental notion that (ex.) 0.1 milliseconds of 
actual CPU/GPU work is ALWAYS, ALWAYS, ALWAYS *both* faster *and* lower 
power drain than (ex.) 10 milliseconds of actual CPU/GPU work. And that 
*that* is *ALL* there is to software efficiency! Nothing more!

So yes, absolutely. If you *are* going to be animating the entire screen 
every frame for a desktop UI (and I agree that's not always a great 
thing to do, in part for battery reasons), then yes, I'd ABSOLUTELY 
rather it be doing so in a game-engine-like way so that it can achieve 
the same results with less demand on the hardware. And if you're NOT 
animating the entire screen every frame, then I'd STILL rather it take 
advantage of a game-engine like architecture, because I'd rather my 
static desktop UI take 0.01% CPU utilization than 2% CPU utilization 
(for example).

> (Once, just out of curiosity (and no small amount of frustration), I
> went into Firefox's about:config and turned off all smooth scrolling,
> animation, etc., settings.  The web suddenly sped up by at least an
> order of magnitude, probably more. Down with 60fps GUIs, I say.  Unless
> you're making a game, you don't *need* 60fps. It's squandering resources
> for trivialities where we should be leaving those extra CPU cycles for
> actual, useful work instead, or *actually* saving battery life by not
> trying to make everything emulate a ≥60fps game engine.)

Yes, this is true. There's no surprise there. Doing less work is more 
efficient. Period. But what I'm continually amazed that the majority of 
non-game developers seem to find so incredibly difficult to grasp is 
that NO MATTER WHAT FRAMERATE or update rate you're targeting: What is 
MORE efficient and what is LESS efficient...DOES NOT CHANGE!!! PERIOD.

If you ARE cursed to run a 60fps GUI desktop, which would you prefer:

A. 80% system resource utilization, *consistent* 60fps, and 2 hours of 
battery power. Plus the option of turning OFF animations to achieve 1% 
system resource utilization and 12 hours of battery.


B. 100% system resource utilization, *inconsistent* 60fps with frequent 
drops to 30fps or lower, and 45 minutes of battery power. Plus the 
option of turning OFF animations to achieve 15% system resource 
utilization and 4 hours of battery.

Which is better? Because letting you have A instead of B is *exactly* 
what game engine technology does for us. This is what efficiency is all 

More information about the Digitalmars-d-announce mailing list