Hi Pekka, On 22 November 2016 at 08:54, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Mon, 21 Nov 2016 19:41:33 +0000 Daniel Stone <dan...@fooishbar.org> wrote: >> On 2 May 2016 at 22:40, Emmanuel Gil Peyrot <emmanuel.pey...@collabora.com> >> wrote: >> The core already has to deal with surfaces overlapping multiple 'real' >> outputs - i.e. running on different paint cycles - today, so I don't >> see that punting clones running on disjoint CRTCs makes that problem >> worse in terms of complexity for the core. We could certainly do >> better with repaint-cycle time reporting[1] in the core, but just >> punting down to the backend only makes that worse rather than better, >> I think. > > about the surface/output overlap here... we certainly do handle a > surface overlapping several disjoint outputs, but I still have not > convinced myself that we handle mutually overlapping outputs properly. > > Why do I say that? Because struct weston_plane has a member called > 'damage', and drm_output_render() directly subtracts damage from the > primary plane. Pretty much every backend does that.
Thanks for this - it's a good point. It's strengthened my resolve a little bit though, especially in the context of https://phabricator.freedesktop.org/T7621, where our problem is that repaint is inseparable from, and damaging[0] to, core state. If we pulled primary_plane out of core, and started calculating repaint data per-call instead, we could kill two birds with one stone. And also promote surfaces to planes even if they do span multiple outputs. Cheers, Daniel [0]: Damaging in the sense of buffer damage, i.e. makes changes to. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel