GNOME Bugzilla – Bug 711575
Export visibility to applications
Last modified: 2021-07-05 14:45:53 UTC
As discussed on fedora-desktop, it would be nice if applications could know about their visibility. OSX has a new API for this: http://arstechnica.com/apple/2013/10/os-x-10-9/15/ (see the visibility section) I could see Totem disabling its video rendering when the application is completely invisible for example (somebody listening to a recorded lecture with video, listening only to the sound).
See also: https://bugzilla.gnome.org/show_bug.cgi?id=703332#c10
(In reply to comment #1) > See also: https://bugzilla.gnome.org/show_bug.cgi?id=703332#c10 Yeah I mentioned this on the list (didn't link the actual bug though). Bastien wanted a way for apps to get access to this information, which makes sense. We just need to agree on a protocol for this. Just set a X property on a the window? _GNOME_YOU_ARE_NOT_VISIBLE or something?
(In reply to comment #1) > See also: https://bugzilla.gnome.org/show_bug.cgi?id=703332#c10 Oh you mean Owen's comment specifically. Well maybe we should let him comment on this bug but there is a difference between redraws not happening despite the app asking for them and an app that volunteerly does not draw. But apps can do other things with this information other then just change how they draw stuff (like throttle or stop other activities).
Yeah, I also want to make sure that apps won't show old contents for a second and then update when they turn their source back on, so we need to tie this into the frame sync counter somehow. A _GTK_VISIBLE property sounds OK to me.
(In reply to comment #4) > Yeah, I also want to make sure that apps won't show old contents for a second > and then update when they turn their source back on, so we need to tie this > into the frame sync counter somehow. Yeah that's what we did in bug #703332 apps should probably not change much re drawing but use the hint for other stuff.
(In reply to comment #4) > Yeah, I also want to make sure that apps won't show old contents for a second > and then update when they turn their source back on, so we need to tie this > into the frame sync counter somehow. That's what the apps on my mobile phone do though, and that's not such a big problem. > A _GTK_VISIBLE property sounds OK to me.
This is a tricky issue - exporting out some bit of internal state in an unstable fashion for Totem to do something with has little risk, of course, but defining it as a public, stable API requires more thinking. Despite what Android phones may do, I don't think we want to get to a situation where when you: Drag a window that was overlapping a video player away Go to the overview Alt-Tab in classic mode The user sees an old frame of a video that's way out of sync with the soundtrack that has been playing all the time, then the video hops forward and starts playing smoothly. This is an implementation detail leaking out and hurting the illusion of having applications that are just there. Either presented behavior is that videos pause when you switch away from them (for some definition of switch away) or it's that they keep on playing. (From what I've seen on Android videos pause when you switch away from them.) When it came to the standard frame behavior there were also considerations like wanting an app to complete the transition to the inactive state immediately and not when the user next made the window visible. We also want to avoid the case where every app draws a frame when it becomes "visible" - because that's going to hurt performance going to the overview or classic-mode alt-Tab. Even sending a PropertyNotify and waking up every app is a little problematical, but probably in the noise. The frame-based approach we have currently doesn't have this problem, because if an app isn't waiting for a frame - if it hasn't drawn recently, then it won't get woken up an won't draw anything new. If we're OK with the PropertyNotify cost - and I am basically - then the docs we'd want for such a property would be something like: This property indicates whether any portion of the window is visible to the user. The window may become visible at any time without waiting for a new frame to be drawn so the window must still be kept redrawn in a condition that is similar to what the user expects, though the frequency of updating can be reduced since there is no need to provide smooth motion. The frequency of drawing using the standard frame synchronization mechanism is automatically throttled by the compositor in this situation, so monitoring this property is only useful if an application is not using the frame synchronization mechanism or can reduce work that it is doing outside of frame drawing callbacks. [ Why _GTK_VISIBLE? What does this have to do with GTK+? ]
(In reply to comment #7) > [ Why _GTK_VISIBLE? What does this have to do with GTK+? ] It's the namespace we use instead of _NET if we want a non-standard property. See _GTK_THEME_VARIANT and _GTK_APPLICATION_ID (both of which are implemented by Qt)
We can use Xlib VisibilityNotify events for this issue, but it only works fine on classic gnome. Here is a test program for VisibilityNotify events: http://stackoverflow.com/questions/1667525/visibility-notify-event-in-pygtk
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.