On Fri, 12 May 2017 11:17:43 -0600 Ryan Sipes <[email protected]> wrote:
> Hey Daniel, > > Thanks for the info! I didn't realize this was higher up the stack. > Reading Pekka's post now! Hi Ryan, indeed, Wayland provides the tools by building in the concept of complete frames and atomic window state updates as a fundamental feature: - Clients are required to post complete (or guaranteed to finish first, e.g. by using fences) frames, that is, completely drawn buffers. - The frame callback in the protocol notifies clients when it's a good time to start drawing the next frame. Also EGL implementations are expected to use this for SwapInterval=1 throttling. The frame callback concept is not tied to vsync though. If a window is completely invisible, it is allowed for a compositor to delay the callbacks indefinitely or reduce them to 1/s or something to throttle down the client. - The presentation timing extension offers more information about the timings. - Many protocol extensions, like those that deal with window states, hook onto wl_surface.commit request as the "latch in all new state in one go". The design principle is that partially drawn or transient (glitch) content or inconsistent content and state will never be composited or shown. How clients and compositors make use of the above tools is up to them, really, but I have faith that all implementations aim to do the right thing and avoid useless rendering (except games that maximize their fps regardless of display capabilities). Some people have actually criticised that there is no guaranteed provision for tearing and unthrottled (not vsync'd) redraws. Yet, at least. Of course clients can always draw as often as they want, but servers will still be vsync'd and not tearing. Thanks, pq
pgpJeEaFbkFU6.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
