[RFC weston]

Quentin Glidic sardemff7+wayland at sardemff7.net
Sat Jul 23 16:03:59 UTC 2016


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


More information about the wayland-devel mailing list