[PATCH weston 2/2] compositor-drm: Fix inconsistency in finish frame timestamps

[Daniel Stone]

Hi,

On 19 February 2013 10:17, Ander Conselvan de Oliveira <conselvan2 at gmail.com
> wrote:

> That's a tricky one. I agree that the timestamp of a frame callback does
> not represent the moment the last attached buffer reached the screen. But
> the timestamp is that of the latest completed flip.
>
> The protocol description for wl_surface::frame reads: "Request
> notification when the next frame is displayed". It does not define if the
> next frame need to contain any newly attached buffer. So except for the
> case of idle_repaint(), one could consider the current implementation
> correct.


If we want to get all smug and tell the client that 'next frame' actually
has no meaning wrt request ordering, we might as well just send the frame
callback instantly.  Seriously, either we should reword the spec, or find a
way to change it.


> If that is what we want, that's a different story. But because of our
> latency, it seems providing accurate timestamps could hinder our ability to
> drive repaint using frame callbacks.
>

The problem (which, to be fair, has only occurred to me reading this mail)
is that we're trying to solve two conflicting usecases: having a simple way
to drive animation timing loops, vs. having accurate timing information for
media players.  Knowing when the frame actually hit the screen (as opposed
to when the compositor processed the request, before it even thought about
beginning to repaint or subsequently flip) is pretty crucial for media
players.  I think this is something we need to serve if at all possible,
but it would probably require both triple-buffering and much smarter
clients to hit full framerate.

Perhaps what we need is to reword frame to make it clear that it's only
when the compositor's started _processing_ the frame, and add a second
(well, third, if you count wl_buffer::release) frame event which lets it
know when the buffer has actually been _presented_.

Thoughts?

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130219/86c15fce/attachment.html>