On Tue, 16 Sep 2014 15:33:19 +0100 Steven Newbury <[email protected]> wrote:
> 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? 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
