[PATCH weston v2 00/11] Grouped output repaint

[Pekka Paalanen]

On Mon, 13 Mar 2017 14:42:26 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Wed,  1 Mar 2017 11:33:59 +0000
> Daniel Stone <daniels at collabora.com> wrote:
> 
> > Hi,
> > I'm submitting v2 of this series after Pekka's review. At this point,
> > we now keep all time values in absolute timespec structs, only using
> > normalisation to nsec for relative comparisons. This required the
> > addition of subtraction helpers, suggested by Pekka, but reimplemented
> > to work with signed rather than unsigned values.
> > 
> > Doing this required prising apart weston_output::repaint_scheduled
> > somewhat, which is no bad thing. Previously it was a tri-state:
> > 0 meant that no repaint would happen without damage occurring, and
> > 1 meant that either a repaint was scheduled to occur at a fixed
> > time in the future, or that the previous repaint had not yet
> > completed, and a repaint would not occur until the next call to
> > weston_output_finish_frame. The only way to differentiate the two
> > was to combine with the state of the output's repaint timer, which
> > as of this series no longer exists.
> > 
> > repaint_scheduled has now been prised apart into a tri-state enum,
> > allowing us to differentiate between the latter two cases, and
> > documented slightly better. This, I think, is no bad thing.
> > 
> > There is also an RFC patch for adjusting repaint timings after
> > multi-frame repaint-window misses. Previously we would only adjust the
> > target repaint time by one frame, if we had missed it. If we had missed
> > the target time by multiple frames, we would schedule a repaint to
> > happen immediately, instead of at the next repaint window. This patch
> > changes the behaviour to target the next repaint window regardless of
> > how many frames we were late.
> > 
> > I am unsure if this behaviour is desirable, so have tagged it RFC: it
> > does not affect the series, and is something I noticed only by
> > inspection.  
> 
> Hi,
> 
> patches 1-8 pushed with the two small edits I suggested:
>    11ae2a3..05df8c1  master -> master
> 
> 
> For patch 9 we have https://bugs.freedesktop.org/show_bug.cgi?id=100115
> 
> Patch 10 should be fine by me and patch 11 I haven't looked at yet.

Hi,

patches 9 and 11 R-b me and pushed:
   c4d7f66..b1f166d  master -> master


I changed the comment in patch 9 and didn't think fdo#100115 should
hold up this patch as we haven't been able to reproduce the issue and
there is no backtrace to check. Also by review everything looked ok.

Patch 10 is still left to brew.


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/20170314/ee0a1e1d/attachment-0001.sig>