Hi Christian On Mon, 14 Mar 2016 16:43:05 -0700 Christian Hergert <christ...@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
pgpBVS69MtMf4.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
