[PATCH weston 2/2] compositor: surface and view output comment fixes

Armin Krezović krezovic.armin at gmail.com
Mon May 16 15:06:21 UTC 2016


On 16.05.2016 17:02, Jonas Ådahl 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.paalanen at 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.armin at gmail.com>
>>
>>> Signed-off-by: Pekka Paalanen <pekka.paalanen at 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.
> 
> 
> Jonas
> 

Thanks for the brief explanation!

>>
>>> +	 * 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;
>>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160516/c9c8ec10/attachment-0001.sig>


More information about the wayland-devel mailing list