D GUI Framework (responsive grid teaser)

[Ola Fosheim Grøstad]

On Thursday, 23 May 2019 at 00:23:50 UTC, Manu wrote:
> it's really just a style
> of software design that lends to efficiency.
> Our servers don't draw anything!

Then it isn't specific to games, or particularly relevant to 
rendering. Might as well talk about people writing search engines 
or machine learning code.

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

Well, it all depends on your priorities. The core difference is 
that (at least for the desktop) a game rendering engine can focus 
on 0% overhead for the most demanding scenes, while 40% overhead 
on light scenes has no impact on the game experience. Granted for 
mobile engines then battery life might change that equation, 
though I am not sure if gamers would notice a 20% difference in 
battery life...

For a desktop application you might instead decide to favour 50% 
GPU overhead across the board as a trade off for a more flexible 
API that saves application programmer hours and freeing up CPU 
time to processing application data. (If your application only 
uses 10% of the GPU, then going to 15% is a low price to pay.)


> I don't think you know what you're talking about.

Let's avoid the ad hominems… I know what I am talking about, but 
perhaps I don't know what you are talking about? I thought you 
were talking about the rendering engines used in games, not 
software engineering as a discipline.


> I don't think we 'cut corners' (I'm not sure what that even 
> means)...

What is means is that in a game you have a negotiation between 
the application design requirements and the technology 
requirements. You can change the game design to take advantage of 
the technology and change the technology to accommodate the game 
design. Visual quality only matters as seen from the particular 
vantage points that the gamer will take in that particular game 
or type of game.

When creating a generic GUI API you cannot really assume too 
much. Let's say you added ray-traced widgets. It would make 
little sense to say that you can only have 10 ray-traced widgets 
on display at the same time for a GUI API. In a game that is 
completely acceptable. You'd rather have the ability to put some 
extra impressive visuals on screen in a limited fashion where it 
matters the most.

So the priorities is more like in film production. You can pay a 
price in terms of technological special casing to create a more 
intense emotional experience. You can limit your focus to what 
the user is supposed to do (both end user and application 
programmer) and give priority to "emotional impact". And you also 
have the ability to train a limited set of workers (programmers) 
to make good use of the novelty of your technology.

When dealing with unknown application programmers writing unknown 
applications you have to be more conservative.


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

If you are talking about something that isn't available to the 
application programmer then that is fine. For a GUI framework the 
most important thing after providing a decent UI experience is to 
make the application programmers life easier and more intuitive. 
Basically, your goal is to save programmer hours and make it easy 
to change direction due to changing requirements.  If OO 
hierarchies is more intuitive to the typical application 
programmers, then that is what you should use at the API level.

If your write your own internal GUI framework then you have a 
different trade-off, you might put more of a burden on the 
application developer in order to make better overall use of your 
workforce. Or you might limit the scope of the GUI framework to 
getter better end-user results.


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

You presume that efficiency is a problem. That's not necessarily 
the case. If your framework is for embedded LCDs then you are 
perhaps limited to under 500 objects on screen anyway.

I also know that Open Inventor (from SGI) and VRML made people 
more productive. It allowed people to create experiences that 
they otherwise would not have been able to, both in industrial 
prototypes and artistic works.

Overhead isn't necessarily bad. A design with some overhead might 
cut the costs enough for the application developer to make a 
project feasible. Or even make it accessible for tinkering. You 
see the same thing with the Processing language.


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

In the early stages it is most important to have freedom to 
change things, but with an idea of where you could insert spatial 
data-structures. Having a plan for where you can place 
accelerating data-structures and algorithms do matter, of course.

But you don't need to start there. So I think he is doing well by 
keeping rendering simple in the first iterations.


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

It is a bit problematic for generic libraries to use worker code 
(I assume you mean actors running on separate threads) as you put 
some serious requirements on the architecture of the application. 
More actor-oriented languages and run-times could make it 
pleasant though, so maybe an infrastructure issue where 
programming languages need to evolve. But you could for a GUI 
framework, sure.

Although I think the rendering structure used in browser 
graphical backends is closer to what people would want for an UI 
than a  typical game rendering engine. Especially the styling 
engine.