Weston, frame callback, and clock

Tue Mar 15 15:30:16 UTC 2016

Hi Christian

On Mon, 14 Mar 2016 16:43:05 -0700
Christian Hergert <christian at hergert.me> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 03/14/2016 06:30 AM, Pekka Paalanen wrote:
> > Hi,
> > 
> > I saw your comments on
> > https://bugzilla.gnome.org/show_bug.cgi?id=763350 .
> > 
> > I wonder if you knew about 
> > http://ppaalanen.blogspot.fi/2015/02/weston-repaint-scheduling.html
> >
> >   
> > which explains how Weston does things. Note, that frame callbacks are
> > nowhere near the vblanks currently.  
> 
> Maybe I'm not understanding this correctly. While the frame callback
> is not near the vblank, it does seem to be giving accurate time about
> the timing of the vblank for presentation. Would this be equally
> accurate to use a page_flip_handler instead of vblank_handler?
> 
> compositor-drm.c has a drm vblank_handler which passes the timespec to
> compositor.c which stashes it as output->frame_time. That gets
> delivered to the client in wl_callback_send_done().

The vblank_handler is used only with overlay planes, which without DRM
nuclear page flip support (patches brewing for Weston by Daniel Stone)
is buggy beyond repair (it will tear and/or reduce the compositor
framerate to a fraction). So Weston will always and only use the page
flip handler, unless you are a developer debugging hardware overlays.
The timings of the two are the same anyway wrt. vblanks AFAIK.

If you read the Wayland protocol spec, wl_surface.frame callback is
meant to tell the client that it is a good time to start drawing the
next frame, which in my opinion means the client has the maximum
possible amount of time left to be able to hit the next vblank possible.

The timestamp delivered by the frame callback is somewhat ill-defined.
The spec does not say in which time base it is, nor how it relates to
vblanks, page flips and presentation. Essentially it's just a
millisecond counter the client can use to compute animation progress
since the previous update. Deltas to previous frame callbacks are
meaningful, absolute value or delta to anything else is not guaranteed.

The Presentation feedback event will come later, so it pushes the
client closer to the edge of missing the next possible vblank for
content update on screen, if the client is redrawing as a response to
that.

https://git.gnome.org/browse/gtk+/tree/gdk/wayland/gdkwindow-wayland.c#n348
seems to not hold completely true anymore for Weston's behaviour, after
the fixes I did that I referred to in my blog post. The backend no
longer starts drawing immediately after sending out frame callbacks.

Estimating compositor presentation times based on the frame callback
timestamp is not meant to be reliable in any way. That's what the
Presentation feedback events are for.

IMHO, there are two basic ways a client can do the timings while
throttled:

1) Redraw immediately as a response to the frame callback. This
maximizes the probability of being able to hit every output refresh
(vblank) steadily, but the latency to screen is between 1 and 2 refresh
periods. I don't think you can get any better timings that way, and you
shouldn't care if you use this method anyway. This is meant to be the
realiable way to drive UI animations, where fluency is much more
important than low latency.

2) Wait for Presentation feedback events, compute the fairly reliable
timing estimates based on that, use your own timers to trigger your
redrawing closer to the deadline (which unfortunately is unknown), and
hope that your redraw is as fast as you expect it to be. The benefit is
that the latency to screen is usually below 1 frame period, and you can
relibaly predict when the next frame will be shown to the user (turn to
light). The downside is that you have less time to draw.

The deadline I mentioned is the time when the compositor samples the
surface contents for its own repaint, it should be clear in the graphs
in my blog post. Once the compositor has sampled, no new frame from
clients will make it to the vblank the compositor is currently
repainting for. New client frames arriving after the deadline but
before the vblank are postponed to the following redraw/vblank.

Currently there is no way for clients to know the deadline. It will
just be somewhere between the Presentation feedback event and it's
timestamp, and the next presentation time predicted by the feedback
event. It is currently like this because different compositors may use
different scheduling tactics, and we don't know if exposing the
deadline in e.g. the Presentation feedback event is useful rather than
restricting of compositor implementations. It is certainly a topic that
could be researched.

It can be assumed though, that the deadline should be closer to the
vblank than the feedback event time, because repainting in a compositor
should not take that long and the deadline should be set to allow the
compositor to just hit the vblank it targets next. But, there are many
things to do before we can measure or adjust the deadline (length of the
repaint window, in Weston terms) automatically For some notes, see:
https://phabricator.freedesktop.org/T14
https://phabricator.freedesktop.org/T7345

So right now it's best to just redraw immediately on receiving the
event you want to throttle on.

However, if you know in the client you are going to run for a longer
period of time, like a video player, you could use both frame callbacks
*and* Presentation feedback events to collect statistics. The feedback
events allow you to sync to the compositor repaint cycle and predict
presentation times, and the frame callback may give an indication when
the previous deadline passed. However, it is quite complicated and it
relies on behaviour that is not exactly specified in the Wayland spec.
It would be better to not assume the frame callback implies anything
about the deadline and just use it as a trigger for repaint, while the
feedback events tell you the next estimated presentation times (you
should be able to rely on it for few next frames, not just one).

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