[opengl] check drawable and context Visual IDs in wglMakeCurrent()

[Raphael]

On Thursday 23 March 2006 20:26, Tomas Carnecky wrote:
> Tomas Carnecky wrote:
> > Changelog:
> >  - fail if the drawable and context Visual IDs don't match.
> >
> > why? because this will produce a BadMatch and crash the application so
> > instead of the crash rather return GL_FALSE and let the application
> > handle it.
>
> Please don't apply this patch yet. It fixes one case but there is more
> to be aware of.
>
> This BadMatch bug is triggered if an application creates a window (with
> a default Visual ID) and a custom (non-default) pixel format, the IDs
> were  0x21 and 0x23 in my case (glxinfo/xdpyinfo report Visual ID in the
> range from 0x21 to 0x70).

yes, the classic wine problem :(

> But! I've seen that World of Warcraft calls wglMakeCurrent() with a
> darawable that has Visual ID 0x71 and a context with Visual ID 0x21. Now
> 0x71 is not defined (according to the glxino output) but it works fine,
> eg. glXMakeCurrent() doesn't produce the X Error in that case.
> So I went up the backtrace, into create_glxpixmap(). I let this function
> fail if it would produce a X Error, eg. if "depth of pixmap does not
> match the GLX_BUFFER_SIZE value of vis".
> Then I had to modify wglMakeCurrent() to respect the create_glxpixmap()
> failure and return FALSE. Works good so far, framerate in WoW went up
> from ~20 to up to 70 fps, average is somewhere between 40-50 !!! This is
> incredible.

good news. But try to see if users aren't too impacted (ie. diff between 
nvidia/ATI drivers)

> So.. in this attachment you'll find a patch that does what I've just
> described. I can't test it on anything else than WoW, so if someone
> would please review it and test with outher opengl/d3d applications it
> would be great.

Sorry no time to test ii :(
but send it to wine-users to see

> Also, it would be great if we could put the *Swap*Buffers() into their
> own log domain, something like 'swapbuffers', because the trace is
> usually useless, only when you explicitly look whether these functions
> are called or not, otherwise they only fill the log with garbage.
>
> thanks
> tom

Regards,
Raphael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060324/9789c5f0/attachment.pgp