using OpenGL to implement a window manager

[Aviv Bergman]

b.t.w. - the "other" os is going the first route, and uses anisotropic 
filtering to reduce pixelization (as far as i understand, 3d ui == 
window transformation):

from http://www.microsoft.com/whdc/archive/GDInext.mspx (the 3-d ui part):

"3-D user interfaces will demand quality filtering. Text comprises a 
large portion of today's user interfaces, and if it's pushed into the 
third dimension, it will have to be as clear and legible in 3-D as it is 
in 2-D. Anisotropic filtering is a requirement for readability. Bilinear 
and trilinear filtering emphatically do not suffice. Note that 
anisotropic filtering for a 3-D user interface is much more important 
than for a game, which with its sustained high speed of animation is 
often not still long enough for the filtering deficiencies to be 
evident. For more details on anisotropic filtering, see the Direct3D 
reference rasterizer"

this way if you have the graphic power - you'll have great results 
(without major changes to the underlying architecture)

aviv



Keith Packard wrote:

>Around 19 o'clock on Apr 23, Jon Smirl wrote:
>
>  
>
>>Another plus or minus. If transparency is not involved some of the cases can
>>paint straight into the display buffer without the need for an intermediate
>>pbuffer. That will lower the VRAM pressure for things like xterm windows.
>>    
>>
>
>Transparency is only one of the many features gained by drawing window 
>contents off-screen.  Of more common importance is the lack of visible 
>exposure damage when moving windows around, and the (possibilty of) 
>synchronized frame/window content updates when resizing windows.  Both of 
>these improve the "feel" of the window environment without affecting the 
>actual display at all.
>
>In a transformed environment, the boundary pixels of the window will need 
>to be composited with the underlying image (or windows); partial pixel 
>coverage being equivalent to translucency, after all.
>
>Even if the application window pixel contents account for the full
>transformation, we'll still generally want to paint them off-screen and
>blend them into place.
>
>I suggest that any system capable of presenting a transformed desktop in 
>real-time likely has sufficient video memory (or AGP space) to store 
>enough window contents for a reasonable display.
>
>One nice thing about making all of these architectural controls external 
>to the window system is that you can still just turn them off and get back 
>to the classic (if somewhat grotty looking) clipping-based composition 
>model.
>
>-keith
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>xserver mailing list
>xserver at freedesktop.org
>http://freedesktop.org/mailman/listinfo/xserver
>  
>