<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Restoring maximized window state in Wayland results in tiny window" href="https://bugzilla.gnome.org/show_bug.cgi?id=783901#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Restoring maximized window state in Wayland results in tiny window" href="https://bugzilla.gnome.org/show_bug.cgi?id=783901">bug 783901</a> from <a href="page.cgi?id=describeuser.html&login=ofourdan%40redhat.com" title="Olivier Fourdan <ofourdan@redhat.com>"> Olivier Fourdan</a> <pre>Humm, is there such a thing as a "cleverly computer saved rect"? >From what I can see, it's just a saved rect, i.e. the size before maximization (as saved in meta_window_maximize()). In meta_window_unmaximize(), the saved rect is restored, it can be shrunk to be less than 80% of the workarea though. But the point is, the saved rect is not cleverly computed anywhere. Besides, it's difficult to compute the position right without having the size being set, and the problem is precisely that when we get to xdg_toplevel_set_maximized() the window size is not known and the placement is not done yet. Prior to commit <a href="https://git.gnome.org/browse/mutter/commit/?id=561d71b">561d71b</a>, that wasn't a problem because the window not being placed yet would have trigger the fallback code path in meta_window_maximize() to simply set "maximize_*_after_placement" and return, without actually saving neither the size nor position. <a href="https://git.gnome.org/browse/mutter/tree/src/core/window.c#n2729">https://git.gnome.org/browse/mutter/tree/src/core/window.c#n2729</a> With commit <a href="https://git.gnome.org/browse/mutter/commit/?id=561d71b">561d71b</a>, we make sure the window is (forcibly) placed in xdg_toplevel_set_maximized(), meaning that the placement is done based on the wrong (unknown) size, and the size is also saved in meta_window_maximize() as window->placed is not set, thus avoiding the fallback path as before. So, the real appropriate fix would be to fix <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - wayland: new window momentarily displays on wrong monitor" href="show_bug.cgi?id=782183">bug 782183</a> and <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - wayland: presenting maximized window is jittery" href="show_bug.cgi?id=781353">bug 781353</a> without forcing the placement. IMHO the real issue with <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - wayland: new window momentarily displays on wrong monitor" href="show_bug.cgi?id=782183">bug 782183</a> and <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - wayland: presenting maximized window is jittery" href="show_bug.cgi?id=781353">bug 781353</a> is that we show the window too "early", ie meta_window_show() gets called from idle_calc_showing() *before* the window is actually placed and maximized, leading to the ugly wrongly placed animation. I would rather fix this properly rather than adding even more "fixes" to placement as this may cause some other subtile breackage elsewhere... I just fail to understand why we end up calling meta_window_show() from idle_calc_showing() in this particular case...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>