_NET_WM_STATE_HIDDEN should be enabled when window isn't visible in any active workspace

[DenisSalem]

I'm submitting a…

[ ] Bug
[x] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

A windowed application is not in _NET_WM_STATE_HIDDEN state when the window is not in a visible workspace (on any screen) so client cannot interrupt rendering and/or idling by checking _NET_WM_STATE.

Desired Behavior

A client which is not in any visible workspace (on any screen) should be aware of its state of invisibility with _NET_WM_STATE_HIDDEN.

Impact

Some graphic applications, like OpenGL based softwares, could substantially reduce CPU/GPU usage by knowing its window state.

[ ] This feature requires new configuration and/or commands

Environment

Output of i3 --moreversion 2>&-:

i3 version:
Binary i3 version:  4.18 (2020-02-17) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.18 (2020-02-17) (pid 21432) abort…)
Loaded i3 config: /home/anonyme/.config/i3/config (Last modified: ven. 13 avril 2018 13:10:51, 90480120 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

- Linux Distribution & Version: Gentoo
- Are you using a compositor (e.g., xcompmgr or compton): compton

[i3bot]

Please note that new features which require additional configuration will usually not be considered. We are happy with the feature set of i3 and want to focus in fixing bugs instead. We do accept feature requests, however, and will evaluate whether the added benefit (clearly) outweighs the complexity it adds to i3.

[Airblader]

From the specification:

_NET_WM_STATE_HIDDEN should be set by the Window Manager to indicate that a window would not be visible on the screen if its desktop/viewport were active and its coordinates were within the screen bounds. The canonical example is that minimized windows should be in the _NET_WM_STATE_HIDDEN state. Pagers and similar applications should use _NET_WM_STATE_HIDDEN instead of WM_STATE to decide whether to display a window in miniature representations of the windows on a desktop.

From this, I don't think setting this atom for windows on unfocused workspaces would be appropriate: if the desktop were active and its coordinates were within screen bounds, a window would be visible.

[DenisSalem]

[...] would not be visible on the screen if its desktop/viewport were active.

Well, actually, there is common cases with i3 where windows are not visible on any screen, because they are set in a non visible (active?) workspace. So in my understanding theses cases fall in state handled by _NET_WM_STATE_HIDDEN.

Not not mention that the rest of the quoted paragraph, from specification, may be subject to interpretation in my humble opinion since i3 do not apply to mentioned cases. Yet, in some commons cases, windows are totally invisible, so it should make sense to notify by any mean the client of its state, if not with _NET_WM_STATE_HIDDEN.

[Airblader]

there is common cases with i3 where windows are not visible on any screen, because they are set in a non visible (active?) workspace

I don't fully understand. Which cases are you referring to?

the rest of the quoted paragraph, from specification, may be subject to interpretation

I'm happy to hear hear you out on how you're interpreting the spec.

since i3 do not apply to mentioned cases

Just because some case like task bar minimization doesn't apply to i3 doesn't mean the entire purpose becomes invalid and we can do with it whatever we want. If it doesn't apply, it doesn't apply — that's it.

Keep in mind that the hidden state is not the only hint applications can use to optimize their performance. Windows on inactive workspaces aren't mapped, I don't know what better hint there could be for an application to conserve resources. It literally tells them that they're not being rendered to screen.

[DenisSalem]

A common case could be the following:

On a single screen configuration I could have a client running, let's say, on workspace 2. But I'm actually working on the workspace 1. The client on workspace 2 is obviously invisible.

"[...] desktop/viewport were active [...]" : Maybe I'm not naming things the proper way, but I guess that a workspace may be defined as a desktop/viewport? Indeed, in quoted specification, it doesn't tell anything about inactive viewport/desktop/workplace, if it make sense. I still believe it's not taking too much liberty to assume that a window in an invisible workspace is similar to a minimized window. In practice, for the user, the window is not viewable on purpose. This is the way I interpret specification. And yes, I am agree with you, just because cases doesn't apply to i3, it doesn't allow to do whatever we want.

That is said, you made a strong point with the mapping hint. I'm not that much experienced with X11 and I wasn't aware of this mechanism that's why I was investigating through _NET_WM_STATE hints. So... I guess this thread may be closed :)

Thank you very much for your explanation!

[Airblader]

I guess that a workspace may be defined as a desktop

Yeah, i3 workspaces are the equivalent of the desktop concept in the specifications.

in quoted specification, it doesn't tell anything about inactive viewport/desktop/workplace

It does say how to handle this case, that's the "if its desktop/viewport were active" part. The hint is to be set if the window is not visible even if the desktop containing it is active.

I also briefly looked into awesomeWM, having precedent is always a good idea, but from my quick scan the hidden state is not tied to tags there either, but purely to the minimized state.

I'm going to close this now as working as intended. :-)

[psychon]

so client cannot interrupt rendering and/or idling by checking _NET_WM_STATE.

Uhm. That's what Expose events and VisibilityNotify events are for...? I agree with @Airblader that HIDDEN is not meant for what you are suggesting.