On Wed, 2014-09-17 at 10:06 +0300, Pekka Paalanen wrote: > 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. > 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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
