GNOME Bugzilla – Bug 765648
Want a way to ensure stability of window dimensions after a fullscreen change
Last modified: 2018-04-16 09:16:17 UTC
Currently, when you call gtk_window_fullscreen/unfullscreen, you would get window_state_event signal to inform the state change if supported. However, when window_state_event is arrived, it seems the dimensions of the window are not guaranteed to be stable yet, and there would be some following configure_event and size_allocate signals to update the dimensions. This is an issue for us (Firefox) because page reflow is expensive, and thus we want to collapse the resize and fullscreen change into one reflow to make it faster. We achieve this on Windows and Mac via synchronously resizing the window directly, since they don't really have a fullscreen mechanism. (Mac has one, but that doesn't fit our model very well, so we don't use it.) The main issue on Linux with GTK+ is that: 1. the dimensions may not be stable when window_state_event arrives, 2. configure_event and size_allocate may not come at all for fullscreen change, so there is no place where the window dimensions are guaranteed to be stable, and the handling code is guaranteed to be called. Would you mind providing some suggestion on this situation? Or probably I'm missing something so it is actually fixable? You may want to see https://bugzilla.mozilla.org/show_bug.cgi?id=1254448 for some more discussions.
I'm afraid there is no good answer for this in general. Using a backend like Wayland, where sizes and decorations are controlled by the client, gives you a better chance.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new