Re: [PATCH 2/2] winex11: track glx windows per thread
On 07/22/2016 03:11 AM, Alexandre Julliard wrote:
Miklós Máté<mtmkls(a)gmail.com> writes:
Hmm, you are right. Mesa does set an XCloseDisplay callback to clean things up for the display connections it encounters. If I use data->display instead of gdi_display for pglXCreateWindow in line 1358 of opengl.c, the tests pass, and no zombie glx windows remain. I don't know if I should dare to take responsibility for this change, though, as I know almost nothing about GDI. If it works then it's the right thing to do. I did some further testing, and it doesn't work. Mesa glx maintains its state per-display, and creating a drawable with one display connection but makecurrent with an other one can lead to bad things. Unfortunately, wine-csmt likes to do those from separate threads, so the thread-specific display connections cannot be used instead of the global gdi_display.
MM
Miklós Máté <mtmkls(a)gmail.com> writes:
I did some further testing, and it doesn't work. Mesa glx maintains its state per-display, and creating a drawable with one display connection but makecurrent with an other one can lead to bad things. Unfortunately, wine-csmt likes to do those from separate threads, so the thread-specific display connections cannot be used instead of the global gdi_display.
So why does it work when we use the window as drawable directly? -- Alexandre Julliard julliard(a)winehq.org
On 08/02/2016 03:37 AM, Alexandre Julliard wrote:
Miklós Máté <mtmkls(a)gmail.com> writes:
I did some further testing, and it doesn't work. Mesa glx maintains its state per-display, and creating a drawable with one display connection but makecurrent with an other one can lead to bad things. Unfortunately, wine-csmt likes to do those from separate threads, so the thread-specific display connections cannot be used instead of the global gdi_display. So why does it work when we use the window as drawable directly?
Sorry, I noticed now that I made a little mistake there. The problem is createwindow vs. createcontext, because makecurrent uses the display connection remembered in the glx context (on its creation). Mesa glx remembers things per-display: basically every glx call starts with struct glx_display *const priv = __glXInitialize(dpy). When an X window is made current to a context (glx 1.0 style), Mesa creates the glx and dri drawables, stores them with the display of the context, and when an other window is made current, finds them with the display of the context, and destroys them. No problem. Except that SW:KotOR wants the contents of its window to be kept even when it is not current to a glx context, and Mesa only supports that with glx 1.3. When a glx window is created (glx 1.3 style), Mesa glx remembers it with the display specified in glXCreateWindow. If makecurrent is called with a glx window and a glx context that were created with different display connections, Mesa doesn't find anything about that window on the display of the context, so it assumes that it's an X window a-la glx 1.0. It tries to assign glx and dri drawables to it, and it ends up bad. Sometimes the X server just rejects the drawing calls, but most of the time it also sends fatal error. I checked the glx specification, and I don't see anything on using multiple display connections. I'm also limited to using Mesa, and can't check how the proprietary drivers handle this issue. MM
participants (2)
-
Alexandre Julliard -
Miklós Máté