[PATCH weston 5/7] Don't delay initial output paint

[Daniel Stone]

Hi,

On 17 February 2017 at 14:22, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Thu, 16 Feb 2017 14:53:39 +0000
> Daniel Stone <daniel at fooishbar.org> wrote:
>> I was about to say 'this doesn't gain us anything', except if all
>> clients do submit and trigger repaint immediately, there's a 7ms grace
>> period where we could potentially group repaints together. I don't
>> think that's something we should be relying on though: desktop-shell
>> has the desktop_ready request for this exact purpose. If anything else
>> is relying on the arbitrary 7ms delay to group the initial repaint
>> together, then someone (to be clear: not me) should fix that.
>
> Agreed.
>
>> fbdev is pretty much beyond hope, so I don't propose to fix that; I'd
>> far sooner delete it. RDP copied fbdev, so doesn't discern between the
>> start-from-dead and start-from-idle cases; I can't even test that, so
>> don't propose to fix that either. The Wayland backend attaches a
>> transparent buffer to the surface, so it can lock on to the repaint
>> loop; it could certainly have this path removed to use the same
>> fallback path, but that's more invasive than I'd hoped for right now.
>> The X11 backend is like fbdev and RDP, except it repaints every 10ms
>> instead of 16; I could guess why, but don't actually know.
>>
>> Anyway, in summary, a good cleanup task for later, but nothing I want
>> to touch right now.
>
> Yeah, though I more thought that if you are calling
> weston_output_finish_frame() with FEEDBACK_INVALID, would there ever be
> use for the (fake) timestamp?
>
> But that's not important now.

Thanks!

I think ultimately you're right, and that we're overloading INVALID.
Really we want to distinguish between three cases:
  - we have a real timestamp from the underlying driver, and this is
literally what drives the repaint loop
  - we have no real timestamp, but if you send us into repaint
immediately, we'll get one
  - there is some semblance of a repaint loop, but we can't reason
about it so here are some fake timings

#1 is obviously handled quite well, and both the DRM and Wayland
backends use this.
#2 is used by the DRM backend as of this series, and could be used by
the Wayland backend
#3 is X11/RDP/fbdev

Disentangling these everywhere would be nice, and we could/should use
separate enums to separate them I'd say. Probably a decent
introduction for anyone relatively new to backend development, or the
repaint cycle (so, everyone).

Cheers,
Daniel