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.
