DlangUI Layout Justification

[Adam D Ruppe]

On Friday, 7 April 2023 at 15:52:02 UTC, Ali Çehreli wrote:
> I don't know how relevant it is but there is also Hipreme 
> Engine that supports Android:

I think the question is if you are doing games vs doing other 
applications. There's some overlap between game and gui, but not 
actually that much. Both draw things to the screen and accept 
user input... but even these two things they tend to do quite 
differently.

Guis tend to favor responsiveness. I know, there's people saying 
"games have to be even more responsive!!!!!" but let me finish: 
games tend to favor *predictability*. (Some exceptions of course.)

A gui will want to respond to input as soon as it can. If I can 
press a key and see a response on screen in one millisecond, 
great! Or, on the other hand, if it takes 200 ms... not so great, 
but I can maybe still live with it.

A game will want to respond to input *on a strict schedule*. 
Responding too fast might break its rules - the world physics 
aren't infinitely precise and are designed with certain limits in 
mind. It might also give an unfair advantage to some players over 
others. Responding too slowly means players will miss their jumps 
and other frustrating feelings of lack of control. But notice 
that if something is *predictably* slow, players will get used to 
it - a lot of things deliberately have some delay according to 
the rules of the game. Something is only ever "too slow" if it is 
inconsistently slow.

Thus it is common for games to poll input on a timer, whereas 
guis wait for input on events.

Both games and guis draw, but games tend to draw many active 
things at once, showing a game world that is changing with the 
passage of time, and guis tend to draw one difference at a time, 
in response to either a user input or some request finishing. 
Sure, some guis will do large animations that are similar to how 
a game works, but these are exceptional circumstances; most the 
time, a game is drawing to keep the screen in sync with the state 
of the game world and most the time a gui is idle, waiting for 
something to happen.

That's just the differences in functionality where they overlap. 
Other things are very different. Games often (but not always) 
value predictable latency audio, to maintain its a/v sync. Guis, 
being idle more often than not, can typically defer opening an 
audio device until they need it, then close it as soon as that 
effect is done. Most games contain themselves to one large, 
multi-role window. Guis often use several, with varying roles 
including temporary single-purpose windows (e.g. popup menus and 
toolips). Guis need to implement a variety of input patterns that 
games rarely care about - interprocess drag and drop, copy and 
paste, ui automation and accessibility apis; guis are more often 
part of a bigger cooperative whole than just on their own. Games 
just want to take whatever global input they get into their own 
self-contained game world, and games are more likely to care 
about joysticks and gamepads than guis.

One library can help with both games and guis but it is unlikely 
to be a complete solution for either, certainly not both.