[sldev] Question involving the rendering of interface windows fromsomeone that doesn't know much about the stuff involved (was Re: Pango (Re:Projects that I'm working on ) )

[Joshua Bell]

Tigro Spottystripes wrote:
> I can probably be considered an outsider in regards to the client code,
> C(++) programming in general, and the technical, practical and other
> limitations involved etc, but I'm curious, what would be in the way of
> rendering each interface window to a texture and applying the texture to
> a quad with the dimensions of the window ?

 From a casual chat with a developer last week: since the current code 
re-renders everything every frame, traditional notions of region 
invalidation* just don't exist in the codebase and would need to be 
shoehorned in. That's work that would be necessary either for 
efficiently rendering all UI to one texture, or individual window to 
separate textures.

Giving each window its own texture is just icing on the cake afterwards, 
and then we have to slap whoever implements wobbly window dragging. 
(More seriously: all modern windowing systems have moved to this 
approach and it would probably result in cleaner UI code for things like 
translucent floaters, but the short term** benefits are limited vs. the 
cost to implement.)

> ps: is it ok to ask things like this in this list or should I refrain
> from doing it again in the future?

Entirely appropriate. (For bonus points, though, always check the list 
archives and/or wiki to see if the question has been asked/answered 
before. For extra bonus points, summarize the discussion to the wiki 
afterwards if there is information worth sharing/preserving.)

Joshua

* For non-UI devs: a typical UI implementation pattern is that when the 
content of a UI element changes (new text arrives, state changes, window 
moves, contents scrolled, etc) the widget "invalidates", or marks as 
"dirty", a region (part or all of the rectangle the widget occupies); in 
the next render pass (often asynchronously, often batched up) only the 
"dirty" parts are redrawn. Plenty of tricks are done to minimize the 
number of pixels touched vs. overhead (e.g. combining dirty regions) and 
the ability of underlying control to render only specific portions of 
their content is limited and the source of much optimization work.

** The long term benefits are that each window of the UI can take care 
of itself, darn it, and not have to deal with invalidation caused by 
other windows in the system covering/uncovering it at unpredictable 
times. Internally, the window usually still needs to manage what parts 
are invalidated/dirty, so you do need that foundation. (In simple UIs 
you can just re-render directly, e.g. re-draw the pixels of a button 
during the mouse event, but that's not generally the case.)