D GUI Framework (responsive grid teaser)

[H. S. Teoh]

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
> sleeping.
> 
> 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
engine!

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


T

-- 
Give me some fresh salted fish, please.