https://bugzilla.gnome.org/show_bug.cgi?id=727452 gtk+ | Backend: Wayland | 3.12.x
--- Comment #14 from Simon McVittie <[email protected]> 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. _______________________________________________ Wayland-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-bugs
