2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました: > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote: > > On Sun, 14 May 2017 14:43:44 +0200 > > Philipp Kerling <[email protected]> wrote: > > > * Am I correct in that if I use zxdg_toplevel (i.e. give this > > > role to > > > a surface), I cannot also use wl_shell_surface? If so, this > > > would be > > > > Yes. wl_shell and xdg_shell suites of protocol extensions are > > mutually > > exclusive, you cannot use both for the same wl_surface. wl_shell is > > the > > deprecated one, and xdg_shell suite is the replacement waiting to > > be > > decleared stable. > > > > > quite a problem. I can see that zxdg_toplevel functionality is > > > mostly superior to that of wl_shell_surface, but it has one > > > omission > > > that is crucial for Kodi: the ability to request a specific > > > refresh > > > rate for fullscreen display. This is needed for closely > > > matching the > > > display and video FPS so duplicated and skipped frames are > > > kept to a > > > minimum. Is this an intentional omission and/or is there > > > anything > > > that provides this functionality? > > > > Hopefully the xdg_shell designers would answer that, but I believe > > it > > has been omitted for now to make it easier to declare the first > > fundamental parts of xdg_shell stable. It is missing a lot, but the > > foundation must agreed upon first before building more on top. > > Rather than combining the FPS request with fullscreening, wouldn't it > be > better to let applications set FPS as a property of the surface? > > That way the client would make a promise that is is going to update > surface contents with periodic commits of the specified rate, > completely > independent of the actual output hardware or fullscreen state. > > The server could use that information to choose the best display > refresh > rate even if not in fullscreen mode. I would not want my compositor to do that, since changing the refresh rate means that the monitor will go blank for a while while resyncing on most hardware. Doing this on a regular basis would be very disturbing. Kodi can get away with it since * it only does it when starting to play a video, * it only does it in full-screen mode when nothing else is on the screen anyway, and * it has the option to wait a configurable amount of time before starting playback to ensure that the mode switch is complete. But I can see how this is the more general solution and also supports the video playback use case. If this operation would include a recommendation that the compositor should try to closely match the requested framerate of currently displayed full-screen surfaces to the vertical refresh rate of the corresponding output, I guess it would be fine.
- Philipp _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
