D GUI Framework (responsive grid teaser)
H. S. Teoh
hsteoh at quickfur.ath.cx
Thu May 23 00:34:42 UTC 2019
On Wed, May 22, 2019 at 05:11:06PM -0700, Manu via Digitalmars-d-announce wrote:
> On Wed, May 22, 2019 at 3:33 PM H. S. Teoh via Digitalmars-d-announce
> <digitalmars-d-announce at puremagic.com> wrote:
> > On Wed, May 22, 2019 at 02:18:58PM -0700, Manu via Digitalmars-d-announce wrote:
> > > I couldn't possibly agree less; I think cool kids would design
> > > literally all computer software like a game engine, if they
> > > generally cared about fluid experience, perf, and battery life.
> > [...]
> > Wait, wha...?! Write game-engine-like code if you care about
> > *battery life*?? I mean... fluid experience, sure, perf, OK, but
> > *battery life*?! Unless I've been living in the wrong universe all
> > this time, that's gotta be the most incredible statement ever. I've
> > yet to see a fluid, high-perf game engine *not* drain my battery
> > like there's no tomorrow, and now you're telling me that I have to
> > write code like a game engine in order to extend battery life?
> Yes. Efficiency == battery life. Game engines tend to be the most
> efficient software written these days.
> You don't have to run applications at an unbounded rate. I mean, games
> will run as fast as possible maximising device resources, but assuming
> it's not a game, then you only execute as much as required rather than
> trying to produce frames at the highest rate possible. Realtime
> software is responding to constantly changing simulation, but non-game
> software tends to only respond to input-driven entropy; if entropy
> rate is low, then exec-to-sleeping ratio heavily biases towards
> If you have a transformation to make, and you can do it in 1ms, or
> 100us, then you burn 10 times less energy doing it in 100us.
But isn't that just writing good code in general? 'cos when I think of
game engines, I think of framerate maximization, which equals maximum
battery drain because you're trying to do as much as possible in any
given time interval.
Moreover, I've noticed a recent trend of software trying to emulate
game-engine-like behaviour, e.g., smooth scrolling, animations, etc..
In the old days, GUI apps primarily only respond to input events and
that was it -- click once, the code triggers once, does its job, and
goes back to sleep. These days, though, apps seem to be bent on
animating *everything* and smoothing *everything*, so one click
translates to umpteen 60fps animation frames / smooth-scrolling frames
instead of only triggering once.
All of which *increases* battery drain rather than decrease it.
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. And
now you're recommending that everyone should write code like a game
(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.)
Give me some fresh salted fish, please.
More information about the Digitalmars-d-announce