Re: Some considerations

[email protected] wrote:
> I'm just a lurker here, but the discussion has been rather interesting. There  
> are some interesting issues that came to mind while reading the list for the  
> last view days.  
>   
> 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?   
>   
> 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  
> RAM. Also, the rendering method that seems to be appearing is a bit different  
> from how OS X does things, and could have major ramifications. If you want to  
> render window contents via OpenGL, you're going to probably have to keep window  
> 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.  

I believe OS-X is now largely accelerated.  A good number of consumer cards 
can actually render into AGP space, though it's not exactly performant.

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

I believe this is set to change, if in fact it is true at all.  A huge amount 
of the work in context switching is down to the driver at the moment, but it 
seems to be steadily moving into hardware.  The forces driving hardware 
development will only see this accelerate.

I'm not suggesting that the GL drivers we have now are the perfect answer to 
what evolves from this design - there will be co-evolution, in terms of new GL 
extensions (and possible special cases for the X server), but also necessary 
optimization of existing paths.

Keith