[RFC] GLX_INTEL_swap_event
Ian Romanick
idr at freedesktop.org
Mon Nov 16 11:51:31 PST 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesse Barnes wrote:
> Kristian, Chris and I met with some of the Clutter/Mutter developers
> last week and came up with a new GLX extension to help GLX integrate
> more naturally into glib style event loops:
> http://people.freedesktop.org/~jbarnes/swapbufferevent.txt
I think I'd replace blit with copy in the spec.
What is the utility to the application of knowing GLX_FLIP_COMPLETE vs
GLX_EXCHANGE_COMPLETE?
The GLX_BUFFER_SWAP_COMPLETE_INTEL event should just return the enum
values instead of 1, 2, or 3. This is what is done for the
GLX_BUFFER_CLOBBER_MASK_SGIX event, for example.
All X events are 32 bytes, but GLX_BUFFER_SWAP_COMPLETE_INTEL is 34
bytes. Perhaps the SBC could be only 4-bytes? Having more than 2**32
buffers swaps seems unlikely. :)
Minor nit... Since many specs have issues lists that are longer than the
spec, we've started putting the issues list at the end. Look at a
recent spec for an example:
http://www.opengl.org/registry/specs/ARB/glx_create_context.txt
> The basic idea is that glXSwapBuffers should be asynchronous (i.e.
> return immediately and swap at some point in the future based on swap
> interval settings, busy buffers, etc.). In order to really take
> advantage of this fact though, it helps if clients can perform other
> work that won't cause them to block (e.g. rendering to one of the busy
> buffers from a previous swap). Since knowledge of the busy buffers or
> which operations might require them may not be present at all levels in
> client code, having a notification arrive when swaps complete can
> help. Clients can process non-GL related code until the event arrives,
> then start preparing their next frame.
>
> Note that this in no way prevents clients from queuing multiple swaps
> (e.g. with triple buffering or N-buffering), it just notifies them when
> swaps complete.
>
> The latest implementation bits for this extension are in my personal
> repos: glxproto, dri2proto, xserver and mesa.
>
> Is this something people feel is generally useful?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksBrT8ACgkQX1gOwKyEAw8B4QCeJIOKjHI3CG0lxPhZak4YS3hF
k1AAnjr7Rw/aJk1+dwrTqF1J55TiBqQC
=XZF2
-----END PGP SIGNATURE-----
More information about the xorg-devel
mailing list