On Wed, May 22, 2019 at 3:33 PM H. S. Teoh via Digitalmars-d-announce <[email protected]> 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 <[email protected]> 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 :)
