On Tue, 2014-09-16 at 14:51 +0300, Pekka Paalanen wrote: > On Tue, 16 Sep 2014 13:26:12 +0200 > Alexander Preisinger [email protected]> 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?
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
