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*.
> now you're recommending that everyone should write code like a game
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
> (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