On Thu, 25 Apr 2013 12:34:13 -0700 Bill Spitzak <[email protected]> wrote:
> Pekka Paalanen wrote: > > > Triple-buffering is especially for sub-surfaces, where the > > compositor may have one wl_buffer busy on screen, and another > > wl_buffer busy in the sub-surface cached state due to the > > synchronized commit mode. To be able to forcibly repaint at that > > situation for e.g. resize, we need a third buffer. > > I cannot see any difference between a subsurface waiting for a commit > on a parent and a normal surface that has not done a commit yet. > There is no need for triple buffering, or if there is it is not a > subsurface requirement. In the server, there are three slots per sub-surface, that may hold a wl_buffer reference: the current buffer on display, the pending buffer waiting for commit, and the cached buffer waiting for the parent commit. Having a buffer in the pending slot does not actually count as the buffer being reserved for the server. Instead, the current slot may temporarily hold two buffers at the same time: before compositor refresh cycle completes, the old current buffer may be kept by the renderer and backend, and the new current buffer is just waiting to get on screen. When a sub-surface is committed (wl_surface.commit), the buffer in pending is moved to either the current or the cache slot, depending on the effective commit mode, and the buffer becomes reserved by the server. This should be clear in the protocol specification. If the target is the cache slot, the previous buffer (if any) in the cache slot is released. If the target is the current slot, the previous buffer (if any) in the current slot will be released when the compositor refresh cycle completes. When the parent's current buffer gets replaced (that is, when the new surface state is _applied_), each of its sub-surfaces' cached buffer is moved to the current slot (new state is applied), depending on the effective commit mode. Why we should not need *four* buffers is because the application should throttle its resizing to the server refresh cycle by using the frame callback on one of the window's surfaces. This guarantees that the old current buffer gets released, before the application repaints again. Just to clarify, the four buffer case would be this: - buffer A is currently on screen, the old current, because the renderer or backend needs it continuously (e.g. directly scanned out) - buffer B is going to screen, the new current - buffer C is in the cache slot, because it is waiting for the parent commit to apply state, and this sub-surface is in synchronized mode - buffer D is being drawn into This is a temporary state, where buffer A is soon released, but the unthrottled client decided to draw before that, so it needs buffer D. > What do you mean by "forcibly repaint for resize"? Resizes of windows > cannot happen until the client produces a new buffer with the resized > contents and does a commit. Otherwise it has to keep showing the old > buffer. Unless you really want to reproduce the biggest ugliness > problem with X? This is all *inside* the client. This is a toolkit patch. The canonical use case for a sub-surface is an application, which has a main surface, and a component in a sub-surface. The forcing is about the application forcing the component to redraw in a new size. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
