Hi, On 17 February 2017 at 14:22, Pekka Paalanen <[email protected]> wrote: > On Thu, 16 Feb 2017 14:53:39 +0000 > Daniel Stone <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
