GNOME Bugzilla – Bug 758563
play bar gets weird position in fullscreen under Wayland
Last modified: 2015-12-02 02:08:46 UTC
Created attachment 316120 [details] screenshot It seem the play bar moves down too far down in fullscreen under Wayland
Created attachment 316121 [details] sceenshot under X
Pretty sure this is another problem with clutter{,-gst} and hi-dpi. Does this happen on a non-hi-dpi system?
Created attachment 316165 [details] screenshot, non-hidpi under wayland Yup, seems so. Tested on totem 3.18.1 now under Wayland, and things look more normal.
Passing this on to clutter, but I'm guessing that it gets a bit confused with margins.
What margins?
This is the only code we use to place the controls popup: https://git.gnome.org/browse/totem/tree/src/backend/bacon-video-widget.c#n6101 Lionel?
Bastien, I'm not sure to understand when the top bar is supposed to be displayed? Only in maximized mode? Or both maximized and fullscreen? I get into situation where it's visible in fullscreen mode.
For example, - Open totem (normal mode) - Double click on header bar to make it maximized - Double click in the video to make it fullscreen The window is displayed in fullscreen but with the header bar.
(In reply to Lionel Landwerlin from comment #7) > Bastien, I'm not sure to understand when the top bar is supposed to be > displayed? Only in maximized mode? Or both maximized and fullscreen? It's 2 different widgets. There's a headerbar/titlebar when maximised, and there's an overlay with another headerbar in fullscreen. > I get into situation where it's visible in fullscreen mode. Are you talking about the shell's top bar, or something else?
(In reply to Lionel Landwerlin from comment #8) > For example, > > - Open totem (normal mode) > - Double click on header bar to make it maximized > - Double click in the video to make it fullscreen > > The window is displayed in fullscreen but with the header bar. It's a header bar or a popup that disappears after a couple of seconds?
Just a quick brain dump : It seems to be a GDK problem. gdk_window_get_origin() reports values from before switching to fullscreen mode. It seems the abs_x/y values of GdkWindow are desynchronized from the actual position of the GdkWindow. The Gdk backend of Clutter uses these values to position the subsurface.
More fallout from the CSD changes going on in GTK? Adding Olivier to the Cc.
(In reply to Emmanuele Bassi (:ebassi) from comment #12) > More fallout from the CSD changes going on in GTK? Adding Olivier to the Cc. I am not sure, totem is CSD so if that was the case, that would affect equally X11 and Wayland. Beside, the CSD patches would not change anything in fullscreen because CSD controls (border shadows and header bar) are not visible when fullscreen.
I think this might be more of a GdkWindow issue. Just as a note, on wayland the video surface is a wayland subsurface positionned at the size location than its input only GtkWidget. In order to get the position right, we need to be able to get the position of the associated GdkWindow when the layout cycle starts. My repro scenario is : - put the window in maximized state - put the window in fullscreen state It seems in both cases Totem's window is the same size. That seems to be the reason for the propagation of the abs_x/y value update to stop. Hence the invalid values gdk_window_get_origin() returns. The values are pretty much off by one fullscreen/non-fullscreen transition.
Created attachment 316305 [details] [review] gtk: stack: set internal gdk window position before allocating children Before allocating its children GtkStack should set its own GdkWindow position. This fixes situations where some of the children will try to compute their position relative to the toplevel widget and get the previous allocation cycle value.
Found it :) Although, there might still be an issue on wayland, the top bar in fullscreen mode is not always visible. That's because of the use of subsurfaces. I think the proper way to fix this is to make the top bar in fullscreen mode part of the Clutter scene, just like the controls. Maybe we can have another bug for this.
Pushed an equivalent, but slightly different fix.