Re: Some considerations

Keith Packard wrote:
> Around 0 o'clock on Nov 26, [email protected] wrote:
> 
> 
>>1) Is anybody here familiar with OS X's windowing system? I ask this
>>because they seem to have solved the issue of synchronizing application and
>>window manager drawing. Each app signals when it has completed drawing, and
>>the overall composition process is synced with the monitor's vertical
>>retrace, to get rid of flicker during movement and opaque resize. I don't
>>know if unmodified X apps can achieve the same result --- do apps reliably
>>use XSync to signal the end of drawing?
> 
> 
> OS X has no nested windows, and so there is no synchronization issue; the 
> single window containing the application contents and the frame 
> decorations is painted by the same application and then handed off to the 
> window system for display.  Simple.
> 
> Composite makes this possible by placing the window manager frame and 
> application contents in the same off-screen buffer.  We need to add some 
> kind of notification mechanism so that the compositing manager knows when 
> the buffer holds synchronized contents.  Even without that, the window 
> system is already a lot less klunky looking; windows move without any 
> flashing or artifacts, and even resize is relatively artifact free.
> 
> Current apps don't use XSync to signal frame complete, but I think it will 
> be relatively easy to retrofit into Qt and Gtk+.

Why do you need an explict end-of-frame marker?

In ordinary Xlib you can issue a bunch of drawing commands but you 
won't necessarily see them until you either do an XSync() or try to 
get an input event.

With ordinary X you can certainly see windows midway through 
redraw/refresh.  So seeing partially updated windows in 
compositor-based server isn't really a new thing.


>>2) Is this server going to have an adverse effect on 3D performance? The large  
>>window buffers hanging around in graphics memory is disconcerting. Its not  
>>going to be a big deal for 3D games, because a full-screen app will quickly  
>>kick out old window buffers after running for some time. However, for a  
>>windowed 3D app (like XSI or Maya), those window buffers will eat into graphics 
> 
> 
> Window buffers which aren't actively updating will be migrated back to 
> main memory if other applications have more pressing need for video 
> memory.  But, if everything is updating all the time, you're gonna need 
> piles of memory to keep everything resident.  Do realize that even a 
> full-screen image is "small" these days -- with 256meg video cards, even 
> several 4meg full-screen images are manageable.

Another possiblity with a compositor-based system is to use shallower 
image buffers for some offscreen windows/images.  xterm, for example, 
would work fine with 8bpp color index that's expanded to 32-bit RGBA 
during composition.  That would be a 3 or 4x memory savings there.

-Brian