[Fwd: Re: CVS Update: xc (branch: trunk)]

[Ian Romanick]

Roland Mainz wrote:
> Ian Romanick wrote:
> [snip]
> 
>>Is there any archival of that discussion?
> 
> Not in the public AFAIK (the "internal feedback" above means here that I
> send emails around and got answers via PM).

Okay, that's what I thought.  Could you summarize why the experts you 
asked thought the problem was with gears?  I'm just curious what their 
rationale was.

>>>an event-driven application model or to call at least |glFinish()|. The
>>>first option wasn't possible (which would be preferable here as both
>>>client and Xserver can run "decoupled" but still avoiding that the
>>>client can send rendering instructions faster then the server can handle
>>>them) as it seems to require GLX 1.3 so I used |glFinish()|.
>>
>>The only part of GLX 1.3 that isn't implemented in X.org *today* is
>>pbuffers.  I added support for GLX_SGIX_fbconfig,
>>GLX_SGI_make_current_read and other GLX 1.3 entry points for existing
>>extensions a year ago.
> 
> Is |GLXPbufferClobberEvent| supported, too ? And will it work in this
> case (indirect rendering and direct rendering) ?

That's part of the pbuffers API and is not supported (yet).  Even if it 
were supported, I don't see how that would help.  The clobber events are 
only generated when an X operation causes part of the pbuffer (or 
window) to be damaged.  For example, you would get a clobber event if 
another window was moved to partially obscure the GL window or if memory 
pressure caused a pbuffer to be kicked out of memory.

You could probably use either the GLX_SGI_video_sync or the 
GLX_OML_sync_control extension, but I don't think we can really support 
that in the indirect software rendering case (it *will* be supported 
when we have hardware accelerated indirect rendering).

http://oss.sgi.com/projects/ogl-sample/registry/SGI/video_sync.txt
http://oss.sgi.com/projects/ogl-sample/registry/OML/glx_sync_control.txt