Hi everyone,
Today I played with a little protocol to supports docks, implementing a
simple client and a weston plugin to test it.
Reusing code from another client of mine, I faced an issue I had
encountered already when creating a protocol for notifications:
There is no way for a client to know the correct scale to render to
before pushing a buffer.
Currently, a client wanting to support output scale will have to use the
wl_surface.enter and .leave events, track the different scale factors,
and render a buffer that will work for all of them.
It works great for normal applications, and the toolkit will take care
of most of the work, if not all. The surface will (should) magically be
rendered at the correct scale when you move it from one output to
another, and everything look good.
However, current implementation in Weston[1] and Mutter[2] do not allow
these events to be used for the *initial* buffer.
While xdg_shell[3] is getting ready to allow clients to provide the
“perfect buffer” right from the start, this output scale issue is annoying.
There are at least three possible solutions:
A) Changing the code to send wl_surface.enter even if no buffer is attached.
B) Add a specific event to wl_surface (or an extension like
wl_perfect_surface) to solve this specific issue, sending the output the
client should optimize its rendering for.
C) Use per-role-protocol events, as I did in my notification-area
protocol[4].
I see no big downside to either solution. Here are a few thoughts about
them:
A) may break for some clients, but it should have at worst the same
effect it has now.
B) and C) will need explicit client support, while A) could work already
for some clients.
B) avoids the duplication in every role-specific protocols, but wording
could be hard to get right to sync the event with role-specific one
(where to put “wl_surface.perfect_scale will be sent before
xdg_surface.configure”?).
C) allows a bit more fine-grained behaviour, e.g. in my
notification-area protocol, all surfaces are tied to one specific
output, thus only one event (before any surface creation) will carry the
information.
Thanks for reading, I hope we can figure out a nice solution to make
even the first frame perfect. :-)
Cheers,
[1]
<https://cgit.freedesktop.org/wayland/weston/tree/libweston/compositor.c?id=a884024eea762621fd6277ad2083847d63f0cf40#n1012>
[2]
<https://git.gnome.org/browse/mutter/tree/src/compositor/meta-surface-actor-wayland.c?id=820a6ab40669ed45af69beb079adbf6680fbdb1e#n268>
[3]
<https://cgit.freedesktop.org/wayland/wayland-protocols/commit/unstable/xdg-shell/xdg-shell-unstable-v6.xml?h=wip/xdg-shell-unstable-v6&id=f764ee14a4e8f4389e34efe4fede738efd5896c9>
[4]
<https://github.com/wayland-wall/wayland-wall/blob/a35a2aa7ae68e35d18d7c93f4425bb996ddf3085/unstable/notification-area/notification-area-unstable-v1.xml#L79>
--
Quentin “Sardem FF7” Glidic
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
