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...