Re: Some considerations

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+.

> 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.

tanstaafl.

> buffers in graphics memory. In contrast, OS X appears to use the CPU to draw  
> window contents. That means they can keep window buffers in AGP memory, which  
> is much more plentiful, and faster for the CPU to draw into anyway.  

We can draw to window buffers in AGP memory *or* accelerated window 
buffers in video memory. The X server migrates objects in and out of video 
memory on the fly to keep the most important things resident in the card.  
Of course, "important" will take some tweaking, but the existing 
architecture makes that quite feasible.

> 3) How is current hardware going to like it? Consumer level stuff is fast, but  
> has a history of not handling concurrency well. It sounds like you want each  
> app to use Cairo, preferably via the OpenGL back-end. The simplest model would  
> be to give each app its own OpenGL context, but I have a feeling that current  
> hardware would really not like that at all.   

Yeah, a million DRI contexts probably isn't the best plan.  That's another
reason why allowing fallbacks to X/Render (or even GLX) might be a good
idea as those would share the X server's DRI context.

> 4) This is probably more long-term, but how's compression going to be handled?  

I have no idea; the obvious answer for now is keep buying bigger video 
cards until your performance is acceptable.  Getting access to AGP space 
and DMA is going to help a whole lot by making system memory more useful 
for holding relatively static window contents, that's one of my main 
motivations in moving to a common OpenGL-based rendering infrastructure.

-keith