compiz on aiglx

[James Jones]

On Thursday 09 March 2006 12:23, Kristian Høgsberg wrote:
>   You could do something like:
>
>    static const int attribs[] = {
>      GLX_DRAWABLE_TYPE,         GLX_WINDOW_BIT,
>      GLX_RENDER_TYPE,           GLX_RGBA_BIT,
>      ...
>      GLX_DOUBLEBUFFER,          GL_TRUE,
>      GLX_INCLUDE_INFERIORS_EXT, GL_TRUE,
>      None
>    };
>
>    fbconfig = glXChooseFBConfig(dpy, scrnum, attribs, &num_configs);
>    ctx = glXCreateNewContext(dpy, fbconfig[0], renderType, NULL, False);
>
> to get a double buffered, include inferior gl context for the root
> window, without worrying about which visual the root window has been
> assigned.

This sounds reasonable.  Could you write up a quick extension spec for this?  
I would rather not have all 3 methods.  If people really are interested in 
using the include inferiors method after an overlay window approach is 
available, it seems best to have it defined as an FBConfig as you suggest.  
We chose an X option only because it was thought this would be a temporary 
solution during the transition period.

> It sounds like Keith and Deron prefer the magic overlay window approach,
> but I think this approach is simpler and a lot cleaner and it almost
> already works, we just need the GLX_EXT_include_inferiors extension.
> That should be pretty easy, though, as it just defines the
> GLX_INCLUDE_INFERIORS_EXT token.

A major benefit of the overlay window is the ability to create the window 
being drawn into with whatever FBConfig you like, rather than relying on the 
root window's visual to contain all required functionality.  This may seem 
like a minor point, but it could be a major if you preferred to render the 
desktop using a stereo visual, or if the default visual did not provide 
stencil bits, etc.  As you say, I think there is room for both approaches, I 
just would hate to see the quick availability of an FBConfig extension kill 
off all interest in the composite overlay window.

> ...
>
> Yup, it comes down to either blocking drawing to the pixmap or adding a
> copy-on-write mechanism.  Both schemes add overhead in the tfp
> implementation, and the repeated binding and releasing of the pixmap
> adds overhead in the compositing manager.

I would argue the overhead of rebinding could be minimized more than the 
implicit copy overhead, and that it is much easier to implement, but you're 
right, both are still sub-optimal.

> Even if your compositing manger uses grabs to prevent updates to the
> pixmap while it is used as a texture, you risk half-finished drawing on
> the screen.  Suppose you have an application that starts repainting its
> window and starts submitting a number of drawing requests.  At any time
> during this sequence of requests can the X server or the kernel decide
> to schedule in the compositing manager, which will then lock the server
> and use the half-finished pixmap contents to recomposite the screen.
> Grabbing ensures that the contents of the pixmap doesn't change while
> you texture from it, but there's no guarantee that the contents was
> consistent to begin with.

I believe this is incorrect to some extent.

-You are correct in saying we will get partial screen updates sometimes, but 
each update should always contain at least a completed single operation.  If 
the X server notified the composite manager of damage to a window before the 
operation had completed, that seems like a bug in the X server.  Applications 
that want all operations to be visible at once should use double buffering.  
This has always been the case.  Otherwise, there isn't any concept of a 
"complete update" in X that I know of.

-When the server is grabbed, any future rendering done by X (e.g, requested by 
the grabbing application over the wire), should occur after any rendering 
done by X before the grab.  Therefore, the pixmap contents will be up to 
date.  So, this works great for non-GL clients, or indirect GL clients that 
call glXWaitX() after they grab the server.

-This leaves us with direct rendering clients.  First, note that when the 
application calls XGrabServer(), it should follow it with a call to XSync() 
to ensure the server grab reaches the X server.  When the server receives the 
grab request, it should prevent any direct rendering clients from submitting 
more rendering to the hardware, and ensure all their submitted rendering has 
completed before processing any new requests.  In other words, the XSync() 
should not return until all outstanding rendering has completed, and no new 
rendering should start while the grab is held.

-At this point, the application can call BindTexImage and be sure of the 
contents of the resulting texture.  When it has finished, it can release the 
texture and the grab.

> To get consistent updates working, we need some kind of protocol between
> the compositing manager and the applications, to pass "ownership" of the
> pixmap contents back and forth.  To begin with the application owns the
> pixmap but once it has finished painting into it the application passes
> ownership to the compositing manager.  Once the application has passed
> ownership it can't touch the pixmap contents.  The compositing manager
> now knows that as long as it owns the pixmap, the contents wont change
> and it can use the contents for compositing.  Once that's done it passes
> ownership back to the application, who is now free to draw into the
> pixmap again.
>
> All I'm trying to say, is that I don't think the copy semantics make a
> lot of sense either, but I think we should try to specify the behaviour
> better in the case where the pixmap receives rendering while bound as a
> texture.  As it is now, reverting to solid pink is a valid behaviour,
> but as you say, most implementations will do the right thing, so lets
> try to specify that.

The current version of the spec floating around contains an attempt at 
defining what you describe.  However, it can be argued that it is no better 
than leaving it undefined.  It is very hard to word this without leaving 
holes.  It would be great if someone could come up with some solid language 
to define the result of texturing from a pixmap while it is being rendered 
to.

> I basically think that the way David uses tfp in compiz currently is the
> most reasonable semantics (alias-sematics), and the bind-as-copy
> semantics compromise the usability of the extension without ensuring
> consitent updates anyway.

I think it is the most desireable behavior, but I disagree that it is the most 
reasonable.  All sides of the equation (the oblivious applications, the X 
server, the X and OpenGL drivers, the composite manager, and ideally a 
bullet-proof specification) must be taken into account when creating a 
reasonable solution.

Thanks,
-James

> Kristian