Stabilizing wl_scaler protocol extension

[Pekka Paalanen]

On Tue, 16 Sep 2014 15:33:19 +0100
Steven Newbury <steve at snewbury.org.uk> wrote:

> On Tue, 2014-09-16 at 14:51 +0300, Pekka Paalanen wrote:
> > On Tue, 16 Sep 2014 13:26:12 +0200
> > Alexander Preisinger preisinger at gmail.com> wrote:
> > 
> > > Hi pq,
> > > 
> > > I use it in my wayland-next branch (for unstable wayland stuff) of 
> > > the mpv
> > > player: http://mpv.io/
> > > In this commit:
> 
> > > https://github.com/mpv-player/mpv/commit/77cc885b44a9e95e5c3c9ae4961b9958ff5cf643
> > 
> > Good to know, thanks.
> > 
> > > I only just now realized that I should just use set_destination 
> > > for my use
> > > case.
> > > So setting the destination separately is definitely a use case and 
> > > I think
> > > the set request is redundant.
> > 
> > True, but I'm worried how many upset people there will be if I break
> > the protocol during the migration by removing or renaming something. 
> > :-)
> > There should be no-one as it's all experimental still, but...
> > 
> > > So far I really like the scaler extensions. But the scaling 
> > > quality has
> > > lots of room for improvement.
> > > I thought about improving the scaling quality, but didn't had the
> > > opportunity to look into it.
> > 
> > You mean in the Weston implementation? Yeah, that could very well 
> > be. I
> > think fixing that would come after
> > https://bugs.freedesktop.org/show_bug.cgi?id=83895
> > as it should make detecting the overall scaling factor a lot easier.
> > 
> > However, I'm more interested in the protocol aspect right now, and
> > there the scaling quality cannot be specified IMHO. We have to leave
> > room for hardware overlays doing the scaling in unknown ways.
> > 
> > 
> 
> Wouldn't it be useful if the protocol could have a method of 
> presenting available scaling methods to the application so that the 
> user could configure the preferred trade-off of performance vs quality?

We cannot enumerate the available scaling methods in the protocol, not
statically in the spec, and not even dynamically (e.g. as arbitrary
strings) at runtime. The compositor might not have any clue what
scaling method a hardware scaler uses.

If we did know, and we exposed that to clients, and clients wanted to
use that, the compositor could not present the client's window at all,
because it is not guaranteed that the hardware scaler is always
available and usable (e.g. a partially occluded window may be
impossible to put on a hardware overlay). Vice versa, if the client
chooses some common scaling method, the compositor just cannot use any
hardware scaler, because the scaling method might not be the one.

We could do it as a hint instead of a requirement, but I'm not sure
there is much benefit in that, considering we do have options for the
user already:

The application has two choices for the user to choose between: use
compositor scaling, or don't use and do scaling itself.

The compositor can also have preferences, like a tick box for "use
dedicated hardware video scaling" or alike, vs. "always use OpenGL for
scaling".


Thanks,
pq