[PATCH] protocol: add set_scaling_filter request to wl_surface interface
Pekka Paalanen
ppaalanen at gmail.com
Fri Dec 20 07:51:54 UTC 2019
On Fri, 20 Dec 2019 12:34:42 +0530
Sameer Lattannavar <sameer.lattannavar at intel.com> wrote:
> This is an extension for wl_surface interface to support
> setting scaling filter. Client can request set_scaling_filter.
>
> Protocol implementation posted at:
> https://lists.freedesktop.org/archives/wayland-devel/2019-December/041098.html
>
> Signed-off-by: Sameer Lattannavar <sameer.lattannavar at intel.com>
> ---
> protocol/wayland.xml | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index f1a13b7..3bb4df6 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1715,6 +1715,33 @@
> <arg name="width" type="int" summary="width of damage rectangle"/>
> <arg name="height" type="int" summary="height of damage rectangle"/>
> </request>
> +
> + <request name="set_scaling_filter" since="3">
> + <description summary="sets the filter to be used for scaling on a output">
> + Blurry outputs during upscaling the video buffer, is a generic
> + issue of graphics industry. One of the major reason behind this
> + blurriness is the interpolation of pixel values used by most of the
> + upscaling hardwares.
> +
> + Nearest-neighbor is a scaling_filter type, which works by filling in the
> + missing color values in the upscaled image with that of the
> + coordinate-mapped nearest source pixel value.
> +
> + Nearest-neighbor can produce (almost) non-blurry scaling outputs when
> + the scaling ratio is complete integer. For example:
> + - input buffer resolution: 1280x720(HD)
> + - output buffer resolution: 3840x2160(UHD/4K)
> + - scaling ratio (h) = 3840/1280 = 3
> + - scaling ratio (v) = 2160/720 = 3
> +
> + In such scenarios, we should try to pick Nearest-neighbor as scaling
> + method when possible.
> + </description>
> + <arg name="scaling_filter" type="int"
> + summary="Positive scaling filter for interpretting type
> + of filter to be used for integer scaling"/>
> + </request>
> +
> </interface>
>
Hi,
why is this something that the client should be able to set?
Why not have the compositor choose the method automatically based
on e.g. content and output resolutions where it can take into
account all the image processing, unlike a client ever could?
The compositor itself is already choosing the scaling methods for
surfaces it decides or needs to scale itself (due to output scale,
buffer scale, wp_viewporter, fractional scaling, etc.). Since KMS
planes are just a compositor implementation detail of how to
realize the composition, the compositor will want to use the same
scaling method in KMS as it uses with its renderer (e.g. OpenGL).
Assuming the above questions are answered and the answers properly
justified, this should be a new extension in wayland-protocols
(like e.g. wp_viewporter is) and not on wl_surface in wayland.xml.
We do not extend the wayland.xml interfaces unless it is absolutely
necessary. We want to keep the fundamental protocol interfaces
generic, simple and maintainable.
Please also do all your Wayland, wayland-protocols, and Weston
patch submissions in Gitlab as per the Contribution guidelines in
each repository.
Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20191220/5a229130/attachment-0001.sig>
More information about the wayland-devel
mailing list