D GUI Framework (responsive grid teaser)

Manu turkeyman at gmail.com
Thu May 23 00:23:50 UTC 2019

On Wed, May 22, 2019 at 3:40 PM Ola Fosheim Grøstad via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
> On Wednesday, 22 May 2019 at 21:18:58 UTC, Manu 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.
> A game engine is designed for full redraw on every frame.

I mean, you don't need to *draw* anything... it's really just a style
of software design that lends to efficiency.
Our servers don't draw anything!

> He said he wanted to draw pixel by pixel and only update pixels
> that change. I guess this would be useful on a slow I2C serial
> bus. It is also useful for X-Windows. Or any other scenario where
> you transmit graphics over a wire.
> Games aren't really relevant in those two scenarios, but I don't
> know what the framework is aiming for either.

Minimising wasted calculation is always relevant. If you don't change
part of an image, then you'd better have the tech to skip rendering it
(or skip transmitting it in this scenario), otherwise you're wasting
resources like a boss ;)

> > There's a reason games can simulate a rich world full of
> > dynamic data and produce hundreds of frames a second, is
> Yes, it is because they cut corners and make good use of special
> cases... The cool kids in the demo-scene even more so. That does
> not make them good examples to follow for people who care about
> accuracy and correctness. But I don't know the goal for this GUI
> framework is.

I don't think you know what you're talking about.
I don't think we 'cut corners' (I'm not sure what that even means)...
we have data to process, and aim to maximise efficiency, that is all.
Architecture is carefully designed towards that goal; it changes your
patterns. You won't tend to have OO hierarchies and sparsely allocated
graphs, and you will naturally tend to arrange data in tables destined
for batch processing. These are key to software efficiency in general.

> So could you make good use of a GPU, even in the early stages in
> this case? Yes. If you keep it as a separate stage so that you
> have no dependencies to the object hierarchy.

'Object hierarchy' is precisely where it tends to go wrong. There are
a million ways to approach this problem space; some are naturally much
more efficient, some rather follow design pattern books and propagate
ideas taught in university to kids.

> I would personally
> have done it in two passes for a prototype. Basically translating
> the object hierarchy into geometric data every frame then use a
> GPU to take that and push it to the screen. Not very efficient,
> perhaps, but good enough to get 60FPS with max flexibility.

Sure, maybe that's a reasonable design. Maybe you can go a step
further and transform your arrangement a 'hierarchy'? Data structures
are everything.

> Is that related to games, yes sure, or any other realt-time
> simulation software. So not really game specific.

Right. I only advocate good software engineering!
But when I look around, the only field I can see that's doing a really
good job at scale is gamedev. Some libs here and there enclose some
tight worker code, but nothing much at the systemic level.

More information about the Digitalmars-d-announce mailing list