Stabilizing wl_scaler protocol extension

[Steven Newbury]

On Wed, 2014-09-17 at 10:06 +0300, Pekka Paalanen wrote:
> 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.
> 
That's true, and or the purpose of getting a scaled output it's still 
better than the "legacy" situation on X, where various APIs/Extensions 
are used to achieve then desired result: VidModeExtension, XVideo, 
GLX, RANDR, Present etc,  along with software scalers.

> The compositor can also have preferences, like a tick box for "use
> dedicated hardware video scaling" or alike, vs. "always use OpenGL 
> for
> scaling".
> 
This is probably sufficient (better?) for my imagined use case.  The 
compositor should know what the capabilities of each supported method 
would be.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140918/ed229a9e/attachment-0001.sig>