D GUI Framework (responsive grid teaser)

[Manu]

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:
> > On Wed, May 22, 2019 at 10:20 AM Ola Fosheim Grøstad via
> > Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
> [...]
> > > But you shouldn't design a UI framework like a game engine.
> > >
> > > Especially not if you also want to run on embedded devices
> > > addressing pixels over I2C.
> >
> > 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.

> I think I need to sit down.

If you say so :)