On Wed, May 22, 2019 at 3:40 PM Ola Fosheim Grøstad via Digitalmars-d-announce <[email protected]> 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.
