-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for coming into this thread so late.
David Reveman wrote: > On Tue, 2007-04-17 at 12:18 +0200, Michel Dänzer wrote: >> [ Apologies for the late followup, I've been away over the weekend ] >> >> On Fri, 2007-04-13 at 17:04 -0400, David Reveman wrote: >>> On Fri, 2007-04-13 at 19:50 +0200, Michel Dänzer wrote: >>>> I wonder why I didn't get any feedback on my proposal: Make >>>> glXQueryExtensionsString take the current context into account when >>>> appropriate. Would it be feasible for compiz to make the context current >>>> before calling glXQueryExtensionsString? >>> That's actually what compiz is doing now as I thought that >>> glXQueryExtensionsString took the current context into account. However, >>> as this is wrong I'd prefer to remove it. >> Why is it wrong? It seems odd that it shouldn't take the context into >> account when the context matters for whether an extension is really >> supported, I'm inclined to consider it a bug. > > A bug in the GLX spec? The GLX spec mentions nothing about contexts in > the description of glXQueryExtensionsString or GLX extensions in > general. It seems pretty clear that GLX extensions are specific to the > connection between the client and the server and that they are not > allowed to be context dependent. If this interpretation of the spec is > correct, any code that relies on the current context being taken into > account is obviously wrong. 100% spot on. There are several extensions that are only supported for direct rendering, so this isn't completely new territory (e.g., GLX_OML_sync_control). In these cases it is up to the application to only use the functionality in conjunction with a direct rendering context. I see two options for GLX_EXT_texture_from_pixmap: 1. Specify that it only works on indirect rendering contexts. Compiz and other apps that use the functionality will have to request indirect contexts (i.e., pass FALSE for the 'direct' parameter of glXCreateNewContext). Since it seems possible that future implementations may be able to support tfp on direct contexts, this doesn't seem very future proof. 2. Add a flag to the fbconfigs to specify whether or not a fbconfig can support tfp. This would be roughly analogous to the existing GLX_X_RENDERABLE flag. Either option requires some modifications to the EXT_tfp spec. Option #2 seems more future proof, but it also requires changes to X server and libGL code. Even though I'll probably get stuck writing that code, I vote for #2. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGJkg5X1gOwKyEAw8RAs1DAKCH78uDo2EK3qekeFS7ARuWlGgKxQCfYQzj KHFxZqm8Xwo0PNyQb2pSlJY= =rXkI -----END PGP SIGNATURE----- _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
