[Wayland-bugs] [Bug 727452] Wayland windows with non-trivial alpha get new content drawn over old

[gtk+ (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=727452
  gtk+ | Backend: Wayland | 3.12.x

--- Comment #14 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2014-04-03 10:04:02 UTC ---
(In reply to comment #13)
> That's because the behavior is specific to reusing surfaces. And in mutter and
> pixman-weston, the compositor doesn't release the surface immediately so GDK
> marks it as busy and falls back to the way we do it in X by using a similar
> surface.

That makes sense - so Mutter and pixman-weston are basically in the same
situation as when I patched out the fast-path altogether (Attachment #273425).

If the slow-path is the only thing that gets tested in practice, perhaps it
would be better to use that as a short-term solution.

> I'm not sure memsetting the whole buffer is correcct for the cases where we
> only redraw parts of the window. 

Hmm, good point. I did think "it's fine, if anything its semantics are closer
to the slow path", but I think that may have been wrong reasoning - the slow
path only copies the redrawn region from the similar surface (overwriting the
corresponding part of the reusable surface), not the entire similar surface.

> I think the problem is that we have no definition inside GDK if begin_paint
> clears the cairo surface or returns a cairo surface with undefined contents.

The comments, and the implementation in GdkWindow, suggest that it's meant to
be OK for it to have undefined contents - so the patch from Comment #8 would be
a more correct approach, if it worked (unfortunately it doesn't, and I still
can't see why not).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.