winex11.drv: cleanup better in X11DRV_WineGL_InitOpenglInfo
philcostin at hotmail.com
Sun Sep 17 06:04:25 CDT 2006
Roderick Colenbrander wrote:
> The problem is that I'm not sure (and I think it is Alexandre his issue
> aswell) whether this patch is a workaround or a real fix. I think that
> wined3d created a GLX context in lets say thread '1' and that it wants to
> create lets say another one in a different thread. If this is the case it
> could happen that for the new thread the x11drv visual needs to be
> 'rechosen'. This causes the 'info' code to be called again. Because this
> code creates a context we mess up the already active context.
> Your patch indeed fixes that by storing the current GLX context and
> restoring it later on. Perhaps there's a nicer way to prevent this issue
> to happen at all.
> In any case I think it might be nicer to use glXGetCurrentContext in case
> there's already some GLX context around. So in that case don't create a
> new context and don't kill it at the end. This would already be cleaner.
>> I don't know myself either. I was just going to wait. I want to add a
>> little more to say about it.
>> It's funny that the patch was only meant to affect the opengl/wgl code
>> and the crashing apps are all d3d ones. However winex11 will now
>> change the context on it's own when doing the opengl query and not set
>> it back. What I noticed a couple weeks ago and now is that winex11
>> does usually gets inited twice, therefore it will change the current
>> context twice. One at the start of the program, and another later on
>> -- maybe on creation of a window or something. By that time wined3d is
>> probably inited too, and making glXMakeCurrent calls too since it's
>> based on opengl. So perhaps winex11 is causing wined3d to trip up at
>> some point by changing the context. So if InitOpenglInfo just sets
>> things back, then wined3d won't go boom.
>> >>From comments in wined3d, I can tell there isn't any "context
>> manager". So what wined3d does at most is very simple management of
>> contextes. We probably need a manager to coordinate things like this
>> better between the two libraries. But that will likely be a bigger
>> patch and to do so... I don't know, we need a fix for all the broken
>> d3d apps now.
At the moment, this patch fixes regressions so if we don't have the code in
there at all, many games do not work.
It may not be the ideal solution but is it not better for now to fix the
regression and think about a proper solution separately without breaking
applications by not having the patch applied?
More information about the wine-patches