2015-01-05 21:17 GMT+01:00 Henri Verbeet hverbeet@gmail.com:
On 5 January 2015 at 20:19, Matteo Bruni matteo.mystral@gmail.com wrote:
2015-01-05 18:33 GMT+01:00 Henri Verbeet hverbeet@gmail.com:
If I'm reading this correctly, this effectively ignores DisabledExtensions for anything newer than GL 3.0. (And at least as far as wglGetProcAddress() is concerned it affects both compatibility and core contexts.)
Hmm, it should still work via filter_extensions().
wglGetProcAddress() calls is_extension_supported(), which calls has_extension(NULL, ...) if major >= 3, so it doesn't go through filter_extensions().
Most applications probably won't care, but in principle applications can use wglGetProcAddress() to check if a function is supported. (As opposed to glXGetProcAddress() that's allowed to return non-NULL for unsupported functions.)
Oh, you're right, I missed that. So I really need the glGetStringi() wrapper.
As an aside, note that winex11.drv also uses "glGetString(GL_EXTENSIONS);" in X11DRV_WineGL_InitOpenglInfo().
That should be fine, that's always a compatibility context created with glXCreateContext().
Right, although in a way that's worse; extensions supported in compatibility contexts aren't necessarily also supported in core contexts. The only reason it will probably work in practice is because of the details of the extensions being checked against that list.
Okay I see, I mentioned in patch 2/5 that the WGL extensions reported by wglGetExtensionsString[ARB|EXT] on Windows don't seem to depend on the GL profile in use but I guess that might just be a coincidence i.e. it just happens that the same extensions are supported in both cases.
So theoretically winex11.drv should generate / store the extensions list for each context. I think I'm going to ignore that part for the time being...