[PATCH 0/1] MR7220: winex11.drv: Update window shape before putting surface image.

[PATCH 1/1] winex11.drv: Update window shape before putting surface image.

[Paul Gofman]

From: Paul Gofman

---
 dlls/winex11.drv/bitblt.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/dlls/winex11.drv/bitblt.c b/dlls/winex11.drv/bitblt.c
index 267a42bd4c7..b6e08eaa6b8 100644
--- a/dlls/winex11.drv/bitblt.c
+++ b/dlls/winex11.drv/bitblt.c
@@ -1829,11 +1829,6 @@ static BOOL x11drv_surface_flush( struct window_surface *window_surface, const R
                 ptr[x] |= alpha_bits;
     }

-    if (!put_shm_image( ximage, &surface->image->shminfo, surface->window, surface->gc, rect, dirty ))
-        XPutImage( gdi_display, surface->window, surface->gc, ximage, dirty->left,
-                   dirty->top, rect->left + dirty->left, rect->top + dirty->top,
-                   dirty->right - dirty->left, dirty->bottom - dirty->top );
-
     if (shape_changed)
     {
 #ifdef HAVE_LIBXSHAPE
@@ -1853,6 +1848,11 @@ static BOOL x11drv_surface_flush( struct window_surface *window_surface, const R
 #endif /* HAVE_LIBXSHAPE */
     }

+    if (!put_shm_image( ximage, &surface->image->shminfo, surface->window, surface->gc, rect, dirty ))
+        XPutImage( gdi_display, surface->window, surface->gc, ximage, dirty->left,
+                   dirty->top, rect->left + dirty->left, rect->top + dirty->top,
+                   dirty->right - dirty->left, dirty->bottom - dirty->top );
+
     XFlush( gdi_display );

return TRUE;

[PATCH 1/1] winex11.drv: Update window shape before putting surface image.

[Marvin]

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=151111

Your paranoid android.

=== debian11b (64 bit WoW report) ===

mf:
mf.c:6785: Test failed: Unexpected hr 0.

user32:
input.c:4306: Test succeeded inside todo block: button_down_hwnd_todo 1: got MSG_TEST_WIN hwnd 0000000001EA00EE, msg WM_LBUTTONDOWN, wparam 0x1, lparam 0x320032

[Paul Gofman (＠gofman)]

This allows the window transparency defined by colour key to be reflected in window shape before the image is put onscreen and avoids overwriting the image behind the now-transparent parts. Usually it is not noticeable as the window behind shaped one will redraw itself. Yet it is not supposed to draw transparent parts and it may be especially noticable under Gamescope where the background behind a window is not redraw and the keyed colour effectively gets visible.

[Rémi Bernon (＠rbernon)]

I don't really understand how this makes any difference? Right now changing shape after drawing pixels will expose pixels that have been obscured by the just drawn pixels, but changing shape before will simply do the same with the previous drawn pixels? In both cases the pixels being exposed are not redrawn if the compositor fails to track shape exposed pixels?

[Paul Gofman (＠gofman)]

It does make a bit of difference.

Compositor doesn't fail to track shape exposed pixels. But it can't predict what we are going to shape-expose ahead of time. App sets transparency colour key for layered window. Then paints it, having parts painted with that colour. Then both shaping and putting the image onscreen happens in x11drv_surface_flush, and XPutImage happens before we let X know about our desired shape, so those "transparent" pixels get painted.

FWIW this is a regression from redesigning this part, before that update_surface_region() was called before XPutImage in x11drv_surface_flush(), that changed.

[Paul Gofman (＠gofman)]

If you mean that compositor is supposed to then repaint what is behind our now-transposed window, then it is what happens most of the time, but also does not necessarily happen if what was below our window transparent pixels was wrongly overwritten doesn't paint anything on repaint. It is certainly a subtle difference and if what is behind is not going to be repainted it is not going to look very well in a generic case anyway. But also it is correct not to paint pixels we should not; it is a very simple change  not introducing any complication; it is how that was done before.

[PATCH 0/1] MR7220: winex11.drv: Update window shape before putting surface image. - approved

[Rémi Bernon (＠rbernon)]

This merge request was approved by Rémi Bernon.