<div dir="ltr">Great, thanks for the info! The future has just become a little brighter :-) <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 2, 2022 at 6:17 PM Jonas Ã…dahl <<a href="mailto:jadahl@redhat.com">jadahl@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Dec 02, 2022 at 06:07:55PM +0300, Maxim Kartashev wrote:<br>
> I wonder if it's possible to set the Wayland buffer scale correctly before<br>
> the window appears on the screen for the first time?<br>
> AFAIU, the sequence of events wrt proper scaling is roughly as follows:<br>
> - receive wl_output.scale for each output<br>
> - create surface, commit<br>
> - receive xdg_surface.configure<br>
> - create and attach a buffer, set_buffer_scale(X), commit<br>
> - receive wl_surface.enter(wl_output Y with scale Z)<br>
> - realize that Z != X, resize the buffer, do set_buffer_scale(Z)<br>
> <br>
> So there's a potential for the window to "twitch" when it first appears on<br>
> some output it didn't anticipate and its scale (and the size of the buffer)<br>
> had to be adjusted. Is there a better way? Or maybe I'm interpreting the<br>
> protocol in the wrong way?<br>
<br>
There is no way right now, but there will be in a future version of the<br>
core Wayland protocol.<br>
<br>
See <a href="https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/220" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/220</a><br>
for details.<br>
<br>
A short summary is that you'll receive a "preferred scale" as part of<br>
the initial configuration that will let you avoid the initial wrong<br>
scale you otherwise risk when on a HiDPI system.<br>
<br>
<br>
Jonas<br>
<br>
> <br>
> Thanks in advance!<br>
> <br>
> Maxim.<br>
<br>
</blockquote></div>