From: Matteo Bruni matteo.mystral@gmail.com
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57411 --- dlls/wined3d/context_gl.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/dlls/wined3d/context_gl.c b/dlls/wined3d/context_gl.c index 6b606617f3d..93282529123 100644 --- a/dlls/wined3d/context_gl.c +++ b/dlls/wined3d/context_gl.c @@ -4355,7 +4355,6 @@ struct wined3d_context *wined3d_context_gl_acquire(const struct wined3d_device * if (!texture) { if (current_context - && current_context->c.current_rt.texture && current_context->c.device == device) { texture = current_context->c.current_rt.texture;
Hi,
It looks like your patch introduced the new failures shown below. Please investigate and fix them before resubmitting your patch. If they are not new, fixing them anyway would help a lot. Otherwise please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=149622
Your paranoid android.
=== debian11b (64 bit WoW report) ===
Report validation errors: ddraw:ddraw1 crashed (c0000005) ddraw:ddraw2 crashed (c0000005) ddraw:ddraw4 crashed (c0000005) ddraw:ddraw7 crashed (c0000005)
I tested this patch with an application from the bug https://bugs.winehq.org/show_bug.cgi?id=57072 that also suffers from a regression caused by the same commit, and the patch helps with it as well. Thanks!
Probably it's worth to mention that with a slightly older version of Wine I get a crash after applying the patch from this MR because apparently current_context**->**c.current_rt.texture is NULL and later texture pointer gets dereferenced. However with wine-9.21 there is no crash, may be texture being NULL is not a problem or current_context**->**c.current_rt.texture is never NULL.
Yeah, I think this is the same as 57072.
The thing that bothers me about it—and the reason I didn't submit anything immediately—is that I don't understand why that should cause flickering, and not just poor performance. I don't suppose you have any insight into that?
Not exactly, no. We are recreating the X + GLX drawable every time though. I don't know that it's too crazy to imagine that somehow an initialized-black picture ends up on the screen for a bit while juggling drawables before wglSwapBuffers() eventually brings the correct image on the screen.
This is causing a crash in ddraw:ddraw1 test_palette_gdi().
On Thu Nov 14 19:21:31 2024 +0000, Matteo Bruni wrote:
Not exactly, no. We are recreating the X + GLX drawable every time though. I don't know that it's too crazy to imagine that somehow an initialized-black picture ends up on the screen for a bit while juggling drawables before wglSwapBuffers() eventually brings the correct image on the screen.
I suppose that's a satisfying enough explanation :-)