On Tue, 22 Nov 2016 09:06:00 +0000 Daniel Stone <[email protected]> wrote:
> Hi Pekka, > > On 22 November 2016 at 08:54, Pekka Paalanen <[email protected]> wrote: > > On Mon, 21 Nov 2016 19:41:33 +0000 Daniel Stone <[email protected]> > > wrote: > >> On 2 May 2016 at 22:40, Emmanuel Gil Peyrot > >> <[email protected]> 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. Indeed, and maybe even allow targeting renderers to arbitrary planes rather than the hardcoded primary plane. Then we'd "just" need the planner from hwc2 if it was a good fit... Thanks, pq > Cheers, > Daniel > > [0]: Damaging in the sense of buffer damage, i.e. makes changes to.
pgpYAOkReq1Zy.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
