Bugzilla

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)
> We know which nsWindow is focused (if any) so we can use that info and get frame callbacks from focused nsWindow only. Question is how it's reliable.

Hm, don't see how that would work. In the end it all comes down to Wayland surfaces - if they are visible and if they are opaque. We have a GTK surface, a moz_container subsurface and lots of tile subsurfaces. Each subsurface, if opaque (which we want whenever possible to allow optimizations in the Wayland compositor), can hide other surfaces below. That's why we currently need `gdk_wayland_window_[add|remove]_frame_callback_surface()`, which makes GTK query frame callbacks from the moz_container surface (in the normal Wayland backend) or from opaque tiles (in the compositor backend), because otherwise GTK would get stuck.

I really don't see any way how we can get away with a single frame callback with the current spec. Thanks for all the well meaning suggestions, but please note: I have thought about the issue for quite some time (and implemented the problematic frame callback optimization in Mutter, and implemented the solution for Firefox in GTK, once for the default and once for the compositor backend), and I'm not the only one (otherwise the GTK API wouldn't have been accepted).

So most likely the tasks now is to come up with a good idea how to define that protocol :)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)
> We know which nsWindow is focused (if any) so we can use that info and get frame callbacks from focused nsWindow only. Question is how it's reliable.

Hm, don't see how that would work. In the end it all comes down to Wayland surfaces - if they are visible and if they are opaque. We have a GTK surface, a moz_container subsurface and lots of tile subsurfaces. Each subsurface, if opaque (which we want whenever possible to allow optimizations in the Wayland compositor), can hide other surfaces below. That's why we currently need `gdk_wayland_window_[add|remove]_frame_callback_surface()`, which makes GTK query frame callbacks from the moz_container surface (in the normal Wayland backend) or from opaque tiles (in the compositor backend), because otherwise GTK would get stuck.

I really don't see any way how we can get away with a single frame callback with the current spec. Thanks for all the well meaning suggestions, but please note: I have thought about the issue for quite some time (and implemented the problematic frame callback optimization in Mutter, and implemented the GTK API as a workaround, and implemented that in Firefox, once for the default and once for the compositor backend), and I'm not the only one (otherwise the GTK API wouldn't have been accepted).

So most likely the tasks now is to come up with a good idea how to define that protocol :)