How to pick the initial (output) scale for a surface?

[Pekka Paalanen]

On Sat, 23 Jul 2016 18:03:59 +0200
Quentin Glidic <sardemff7+wayland at sardemff7.net> wrote:

> 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].
> 

Hi,

without a buffer, the surface size is unknown. Even if the WM was able
to position a surface without knowing its size, the surface might span
more than the initial output if the size is large enough. This would be
a problem if the initial output has a scale less than the additional
output it will end up to. This problem is common to A, B, and some
cases in C.

Option B with its "optimize the surface for this output" event would
solve more than just the issue in question. A compositor could drive it
based on which output has e.g. at least 80% of the surface, or
otherwise send the occupied output with highest scale. But is that a
good thing?

> 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. :-)

I think it might not be reasonably possible for all cases, but if we
ignore the unknown size issue, maybe then.

I don't have good suggestions.

Currently what clients already have is the list of all outputs. As the
initial scale, they could pick the highest scale present when they do
not know which output the window will appear on (e.g. do not start
fullscreened on specific output). It does not remove the possibility
for the glitch, but we can at least pick the direction which way the
scale will change if we guess wrong, and there is a good possibility to
also guess right.

That would be consistent with the heuristic of picking the highest
scale from the outputs a surface is on after it has been mapped. Don't
toolkits do that already?


Thanks,
pq

> [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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160729/d4d7284c/attachment.sig>