D GUI Framework (responsive grid teaser)

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Wed May 22 22:39:20 UTC 2019

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.

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.

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

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

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

More information about the Digitalmars-d-announce mailing list