D GUI Framework (responsive grid teaser)

[Manu]

On Wed, May 22, 2019 at 5:34 PM H. S. Teoh via Digitalmars-d-announce
<digitalmars-d-announce at puremagic.com> wrote:
>
> 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?

Yes, but I can't point at many industries that systemically do that.

>  '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.

And how do you do "as much as possible"? I mean, if you write some
code, and then push data through the pipe until resources are at
100%... where do you go from there?
... make the pipeline more efficient.
Hardware isn't delivering much improvement these days, we have had to
get MUCH better at efficiency in the last few years to maintain
competitive advantage.
I don't know any other industry so laser focused on raising the bar on
that front in a hyper-competitive way. We don't write code like we
used to... we're all doing radically different shit these days.


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

That's a different discussion. I don't actually endorse this. I'm a
fan of instantaneous response from my productivity software...
'Instantaneous' being key, and running without delay means NOT waiting
many cycles of the event pump to flow typical modern event-driven code
through some complex latent machine to finally produce an output.

> All of which *increases* battery drain rather than decrease it.

I'm with you. Don't unnecessarily animate!

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

You're conflating a lot of things here... running smooth and eating
GBs of memory are actually at odds with eachother. If you try and do
both things, then you're almost certainly firmly engaged in gratuitous
systemic inefficiency.
I'm entirely against that, that's my whole point!

You should use as little memory as possible. I have no idea how a
webpage eats as much memory as it does... that's a perfect example of
the sort of terrible software engineering I'm against!

> Such is the result of trying to emulate game-engine-like behaviour.

No, there's ABSOLUTELY NOTHING in common between a webpage and a game
engine. As I see, they are at polar ends of the spectrum.
Genuinely couldn't be further from each other in terms of software
engineering discipline!

> And now you're recommending that everyone should write code like a game
> engine!

Yes, precisely so the thing you just described will stop.

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

You're placing your resentment in the wrong place.
My 8mhz Amiga 500 ran 60hz gui's without breaking a sweat... you're
completely misunderstanding the actual issue here.

> Unless you're making a game, you don't *need* 60fps.

Incorrect. My computer is around 100,000 times faster than my Amiga
500. We can have fluid execution.
We just need to stop writing software like fucking retards. The only
industry that I know of that knows how to do that at a systemic level
is gamedev.

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

You've missed the point completely.
You speak of systemic waste, I'm talking about state-of-the-art
efficiency as baseline expectation and nothing less is acceptable.