[PATCH weston v2 10/11] [RFC] Account for very large repaint window misses

[Pekka Paalanen]

On Thu, 30 Mar 2017 23:07:29 +0200
Mario Kleiner <mario.kleiner.de at gmail.com> wrote:

> On 03/30/2017 11:53 AM, Pekka Paalanen wrote:
> > On Wed, 29 Mar 2017 22:35:46 +0200
> > Mario Kleiner <mario.kleiner.de at gmail.com> wrote:
> >  
> >> On 03/29/2017 12:30 PM, Pekka Paalanen wrote:  
> >>> On Tue, 28 Mar 2017 20:53:53 +0200
> >>> Mario Kleiner <mario.kleiner.de at gmail.com> wrote:
> >>>  
> >> ...  
> >>>>
> >>>> Agreed. The adjustment can never be more than 1 refresh period, ergo
> >>>> doesn't need a loop, unless we'd get the very unlikely case of Weston
> >>>> getting preempted for a long time exactly during the few instructions
> >>>> leading from output->start_repaint_loop to weston_output_finish_frame
> >>>> reading the compositor clock. In which case we'd glitch badly in any
> >>>> case. I can't think of a way, apart from kms driver bug, that the
> >>>> pageflip event could carry a bad timestamp, and for the pageflip driven
> >>>> path we don't hit that one-shot adjustment (or potential loop) anyway,
> >>>> as the flags aren't WP_PRESENTATION_FEEDBACK_INVALID.  
> >>>
> >>> Oh, that is true about the pageflip fallback path of
> >>> start_repaint_loop. Makes me wonder if I should "fix" that, since
> >>> start_repaint_loop should never result in sending out presentation
> >>> feedback events, and can't assert on that if the flags are not
> >>> FEEDBACK_INVALID. Oh well, I've been meaning to get rid of the INVALID
> >>> flag by introducing a different function to call in that case.
> >>>  
> >>
> >> I think that can't happen, because we only copy the pending feedback
> >> events for a surface into the list for an output in the call sequence:

...

> >
> > Assert()s generally are for things that "can't happen". ;-)
> >  
> 
> Maybe i misunderstood what you meant. I meant it can't happen that we 
> send out presentation feedback during any restart of the repaint loop, 
> regardless if regularly or via the pageflip fallback.

Yes, it cannot happen. Or rather, it should never happen. The assert()
is there to point out existing or future bugs hopefully before they get
into a release. It's a form of defensive programming.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170331/0584e6b5/attachment.sig>