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.) _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
