[PATCH weston 2/2] compositor: Skip repaint delay for nested compositors

[Pekka Paalanen]

On Thu, 2 Apr 2015 13:29:53 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Wed,  1 Apr 2015 12:37:34 -0500
> Derek Foreman <derekf at osg.samsung.com> wrote:
> 
> > The repaint delay becomes cumulative if it's used in both a parent
> > compositor and a nested compositor.  This can lead to dropped frames
> > and visible latency.
> > 
> > Signed-off-by: Derek Foreman <derekf at osg.samsung.com>
> > ---
> >  src/compositor.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/src/compositor.c b/src/compositor.c
> > index 4de8fbf..433f6d2 100644
> > --- a/src/compositor.c
> > +++ b/src/compositor.c
> > @@ -2412,6 +2412,14 @@ weston_output_finish_frame(struct weston_output *output,
> >  	msec = (refresh_nsec - timespec_to_nsec(&gone)) / 1000000; /* floor */
> >  	msec -= compositor->repaint_msec;
> >  
> > +	/* If nested outputs try to use a repaint window the delay sums
> > +	 * with the parent's delay and we start dropping frames...
> > +	 */
> > +	if (compositor->nested) {
> > +		output_repaint_timer_handler(output);
> > +		return;
> > +	}
> > +
> >  	if (msec < -1000 || msec > 1000) {
> >  		static bool warned;
> >  
> 
> Yeah... except the "dropping frames" part does not make sense to me.
> 
> When the parent compositor sends a frame callback, it is already too
> late for the child compositor to hit the very next vblank in absolute
> time. Instead, the child compositor now has almost a whole frame
> period's time until the deadline set by the parent compositor for the
> following vblank. So, it might just as well wait that 9 ms or whatever,
> it should still hit the very same vblank as it would by rendering
> immediately.
> 
> There must be something else going on here.
> 
> I can definitely reproduce problems with Weston/wayland nested in
> Weston/DRM.
> 
> I have a hunch the problem lies in the Wayland backend's finish-frame
> timestamps, which have no relation to the presentation clock used in
> the wayland backend... will investigate.
> 
> A proper solution would be to make the Wayland backend use the
> Presentation extension, but we also do need a way for it to work fine
> if there is not Presentation available.

Ok, I've sent a patch:
http://lists.freedesktop.org/archives/wayland-devel/2015-April/021026.html

That should fix the fallback case (the only case we have implemented
atm.).


Thanks,
pq