Hi.

I am wondering about this. I am curious as to how you efficiently program a "widget" GUI system, that is, a part of a program that draws interface windows with buttons and scrollbars and that type of stuff (widgets) on them.

I have done this a couple times before but I was not really satisfied with my previous attempts and am now curious about how you really make it efficient and clean. In particular, what I have is this: I represent the windows and widgets by a tree structure, which is "natural" because it has a natural hierarchical structure, in which the root node represents the whole screen, and then below that we have nodes for the windows, then each window node has nodes for the widgets, then each widget node has nodes for the components of the widget (It could go further, in theory, but this is as far as I go). The order in which the widgets/windows overlap (from front to back) is determined by the ordering of them as siblings on the tree -- the nodes keep pointers to the next sibling in a linked list.

The trouble is that I am trying to figure out how to make the render/drawing as quick and efficient as possible -- in particular, we may know that only certain widgets or components need to be redrawn, so we shouldn't need to explore every node of the tree, but we also have to deal with resolving overlap: we shouldn't redraw something with a higher position on the order if it doesn't actually overlap anything, but we also may not want to keep exploring the whole structure to check for overlaps every time we do a redraw. How can we efficiently do this whole process, including the overlap resolution, the latter ideally without having to check every sibling?

This has to have an already-existing solution since window-based GUIs are so ubiquitous. I am just not sure where to find a good description of it. What would that be?

Qt handles all that. If I was making a non-gaming application requiring native look and feel, I'd use Qt (which I am).

If I was making a videogame, videogames usually have rather simple GUIs, and redrawing them every frame isn't much of a cost (a hundred or so polygons). I'd only bother caching the text, because generating the text can cost alot; I'd assume anything else is premature optimization at this point in time, and only work to optimize it if it proves a bottleneck by profiling later in development.

But if I was to implement it myself, I'd just give each widget a "needsRedrawing" boolean.

It's get set to false each time it gets redrawn, and it'd get set to true when events occur that require redrawing.

For example, if a button is hovered over, the button will want to redraw itself with a hover appearance (and may want to keep redrawing itself for several frames of animation).

Or if a widget gets moved, the parent widget needs to be marked for redrawing.

If a widget is marked as 'needsRedrawing', all its children also get redrawn.

I don't understand what you're talking about with the overlap. Do you mean draggable windows that float over other windows?

I don't understand what you're talking about with the overlap. Do you mean draggable windows that float over other windows?

Overlap means yes, windows/widgets overlapping on top of each other. Not necessarily draggable -- just on top of each other, e.g. a menu and then you open up a sub-menu which floats above.

Well, for floating windows, when they appear they don't need to invalidate anything (they're drawing over it anyway).

While they are still showing, a floating window doesn't need to invalidate anything either.

Only once a floating window gets hidden again (or moves) do they invalidate.

So when a floating window gets hidden, then get its previous rect (or, if moved instead of hidden, get the rect for just the now-uncovered area), and test that rect against the widget tree. For any widget that overlaps the 'now exposed' rect, invalidate that widget, and check its children for overlap. For any widget that isn't overlapped, don't invalidate it, and you don't even need to bother checking the children.

This sort of thing was a great efficiency savings back in the days of 16-bit processors and single-digit megabytes of RAM. It's not clear it is worth worrying about these days. I'd take even odds that the cost of recursively updating all the needsRedraw flags is damn near as much as just drawing the whole thing again.

I have to say you are wrong here, at least in the GUI-libary I wrote, doing this "dirty" checking resulted in enormous speedups, in the range of multiple ms on all machines. Its one of the first optimizations I would recommend when trying to improve the performance of a (non-game) GUI. It can easily be justified by how little there actually has to be redrawn regularily (nothing if you don't move the mouse cursor ie.), and the benefit from even skipping say rendering a single tree-view/attribute table already outweights any loss from keeping track of what needs to be redrawn. You might not need it to get 60 FPS, but since you want to do other stuff in your application as well, it can still save a lot of processing power for those things.