On Mon, 16 May 2016 23:02:42 +0800 Jonas Ådahl <jad...@gmail.com> wrote:
> On Mon, May 16, 2016 at 04:45:05PM +0200, Armin Krezović wrote: > > On 10.05.2016 16:10, Pekka Paalanen wrote: > > > From: Pekka Paalanen <pekka.paala...@collabora.co.uk> > > > > > > weston_surface::output and weston_view::output as used for different > > > purposes. Only the surface output is used for frame callbacks. > > > > > > The uses of the view output are much more vague and hard to describe. > > > > > > Also fix a comment mistake in weston_surface_assign_output(). > > > > > > > All the changes look fine to me. I have one comment below, as I'm not sure > > if it's a mistake or not. > > > > In case it isn't a mistake (or with the mistake fixed, in case it is one), > > this patch is also: > > > > Reviewed-by: Armin Krezović <krezovic.ar...@gmail.com> > > > > > Signed-off-by: Pekka Paalanen <pekka.paala...@collabora.co.uk> > > > --- > > > src/compositor.c | 8 +++----- > > > src/compositor.h | 5 +++-- > > > 2 files changed, 6 insertions(+), 7 deletions(-) > > > > > > diff --git a/src/compositor.c b/src/compositor.c > > > index ee47a82..40d8baf 100644 > > > --- a/src/compositor.c > > > +++ b/src/compositor.c > > > @@ -1082,16 +1082,15 @@ weston_surface_update_output_mask(struct > > > weston_surface *es, uint32_t mask) > > > } > > > } > > > > > > - > > > /** Recalculate which output(s) the surface has views displayed on > > > * > > > * \param es The surface to remap to outputs > > > * > > > * Finds the output that is showing the largest amount of one > > > * of the surface's various views. This output becomes the > > > - * surface's primary output for vsync and frame event purposes. > > > + * surface's primary output for vsync and frame callback purposes. > > > * > > > - * Also notes the primary outputs of all of the surface's views > > > + * Also notes all outputs of all of the surface's views > > > * in the output_mask for the surface. > > > */ > > > static void > > > @@ -1136,8 +1135,7 @@ weston_surface_assign_output(struct weston_surface > > > *es) > > > * > > > * Identifies the set of outputs that the view is visible on, > > > * noting them into the output_mask. The output that the view > > > - * is most visible on is set as the view's primary output for > > > - * vsync and frame event purposes. > > > + * is most visible on is set as the view's primary output. > > > * > > > * Also does the same for the view's surface. See > > > * weston_surface_assign_output(). > > > diff --git a/src/compositor.h b/src/compositor.h > > > index 7851000..0801f20 100644 > > > --- a/src/compositor.h > > > +++ b/src/compositor.h > > > @@ -949,8 +949,9 @@ struct weston_view { > > > } transform; > > > > > > /* > > > - * Which output to vsync this surface to. > > > - * Used to determine, whether to send or queue frame events. > > > + * The primary output for this view. > > > + * Used for picking the output for driving view animations, inheriting > > > > Is the correct term "driving animations" or "drawing animations" ? > > It is actually "driving" here. One surface may be drawn on multiple > outputs, but only one output will "drive" the animation. > > Driving the animation means to respond to frame callbacks, and since > outputs may be rendered independently, we tie the animation of a surface > to only one output. > > For example: a client rendering an animation will attach and commit a > new buffer of a frame of its animation, and ask for a frame callback. > Then it will wait for the frame callback until it draws, attaches and > commits the buffer of the next frame of its animation. > > In order to get as good results as possible, meaning content drawn by > the client should end up on the output as quickly as possible, we > calculate the output it has the largest overlapping region on, and > whenever that output was painted, we reply to the frame callback. > > If we for example would wait until all outputs the surface is one is > drawn on until replying, we would potentially delay the frame callback, > making the latency between the client drawing and the content being > displayed on the output, unnecessarily long, since we would effectively > let the output drawn last, no matter how large portion of the surface is > drawn on it, always "drive" the animation. That is all true for client-drawn animations. However, weston also has an internal animation framework, see src/animation.c, which primarily does view animations: changing view parameters over time, like size, position, or opacity. Also this animation framework is driven by a single chosen output of a view, for the reasons Jonas explained. To recap, client-drawn animations are driven by weston_surface::output repaint cycle, and server-side view animations are driven by weston_view::output repaint cycle. Clients only "know" about weston_surface (wl_surface), they are completely unaware of how many weston_views it might have. Therefore it makes sense to drive the client repaint cycle with the client perspective, and server-side animation cycle according to the view it is applied on. (Btw. the reason we sync all animations everywhere to the most appropriate output's repaint cycle instead of using a timer is to get the frame drawn exactly for the time it will be shown, avoiding jitter and wasted drawing. You cannot show a new frame at arbitrary times, so better lock on to the times it can happen.) > > > > > + * the primary output for related views in shells, etc. > > > * Must be NULL, if 'link' is not in weston_compositor::view_list. > > > */ > > > struct weston_output *output; > > > Thanks, pq
pgpLSaVY2xsFe.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel