Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content of workspaces (screen background) visible on others (mplayer) #3795

Open
klartext opened this issue Sep 17, 2019 · 8 comments · May be fixed by #3810

Comments

@klartext
Copy link

commented Sep 17, 2019

I'm submitting a…

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

Current Behavior

i3 4.17.1: Background of one workspace is visible, when switching to a different workspace.

Expected Behavior

When switching from one workspace, the contents that was seen on the former workspace is not visible anymore.

Reproduction Instructions

Example reproduction:
One workspace with alsamixer that fills the screen (one tile only).
Then switch to a different workspace (I had more than one tile, but I think this does not matter here). If the used tile is not completely used by the program on the newly encountered (switched to) workspace, the contents of the former worksapce frames the new workspace.

Environment

Arch Linux.
Package that works is 4.16.1-1.
Package with the problem is 4.17.1-1.

After finding the problem I downgraded to the older version to be sure, that no other package-installations have caused the problem.
I found out that with downgrading to 4.16.1-1 the problem was gone.
So the problem is a i3-problem.

Output of i3 --moreversion 2>&-:

i3 version: 
Binary i3 version:  4.16.1 (2019-01-27) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.16.1 (2019-01-27) (pid 28339)bort…)
Loaded i3 config: /home/oliver/.i3/config (Last modified: Sa 02 Mär 2019 23:50:22 CET, 17187316 seconds ago)

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

See discussion on i3-mailinglist:
https://www.freelists.org/archive/i3-discuss/09-2019

Screenshots:

a) with the problem:
http://s000.tinyupload.com/?file_id=53830511177154834717
i3-Problem_s

b) after downgrading, expected behaviour:
http://s000.tinyupload.com/index.php?file_id=16308606597116519931
i3-wm_4-16-1_s

@i3bot

This comment has been minimized.

Copy link

commented Sep 17, 2019

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

@i3bot i3bot added the 4.17 label Sep 17, 2019
@Airblader

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

As mentioned on the mailing list, since we have a bad and a good version, a git bisect would be helpful to figure out which commit actually causes this.

@klartext

This comment has been minimized.

Copy link
Author

commented Sep 25, 2019

OK, I used git bisect to locate the problem.
Here the output:

29f2510fa9484a5fa235de9a1c5c937292151888 is the first bad commit
commit 29f2510fa9484a5fa235de9a1c5c937292151888
Author: Orestis Floros 
Date:   Mon Oct 1 19:47:33 2018 +0300

    Fix aspect ratio bugs
    
    - ICCCM says: > If a base size is not provided, the minimum size is to
    be used in its place and vice versa.
    i3 didn't obey the "vice versa" part. Min size and base size are both
    saved without replacements in window_update_normal_hints,
    floating_check_size makes the needed replacements if either was not
    provided.
    - Aspect ratio is now saved correctly in manage_window because
    window_update_normal_hints is called.
    - i3 didn't save the aspect ratio if the window conformed the given
    aspect ratio range when handle_normal_hints was called. If the window
    was resized to a size outside of the given bounds, i3 didn't correct it.
    - Aspect ratio now affects only tiling windows, like the rest of the
    normal size hints
    - The aspect ratio calculation is now done without a loop
    
    A real life example of how these changes affect the workflow:
    An mpv window, when playing a video, sets its min == max aspect ratio
    during mapping. i3 ignored these hints. When resized, the window's
    aspect ratio was not preserved. With this commit, resizing floating mpv
    windows will always preserve the aspect ratio.

 include/data.h               |   3 +-
 include/floating.h           |  13 +++--
 include/window.h             |   6 ++
 src/commands.c               |   2 +-
 src/con.c                    |   1 -
 src/floating.c               |  85 ++++++++++++++++++++++------
 src/handlers.c               | 130 ++-----------------------------------------
 src/load_layout.c            |   2 +-
 src/manage.c                 |  34 ++---------
 src/render.c                 |  29 ----------
 src/scratchpad.c             |   2 +-
 src/window.c                 | 121 ++++++++++++++++++++++++++++++++++++++++
 testcases/t/133-size-hints.t | 104 +++++++++++++++++++++++++++-------
 13 files changed, 304 insertions(+), 228 deletions(-)

#3432

@Airblader

This comment has been minimized.

Copy link
Member

commented Sep 25, 2019

Thanks, that's very helpful!

@orestisfl Maybe you can have a look?

@orestisfl

This comment has been minimized.

Copy link
Member

commented Sep 25, 2019

Thanks, I can reproduce this specifically with mplayer. Mpv (so you can use it as a workaround) does not have this issue, I'll try to find where the fault lies.

@orestisfl

This comment has been minimized.

Copy link
Member

commented Sep 26, 2019

btw both i3 4.16 and awesomewm have this issue with fullscreen mplayer

@orestisfl orestisfl changed the title Content of workspaces (screen background) visible on others Content of workspaces (screen background) visible on others (mplayer) Sep 27, 2019
@orestisfl orestisfl self-assigned this Sep 27, 2019
@Airblader

This comment has been minimized.

Copy link
Member

commented Sep 28, 2019

Yeah, MPlayer is known to be misbehaving, here. I'm fairly sure we discussed this before, and I would guess awesome did as well.

@orestisfl

This comment has been minimized.

Copy link
Member

commented Sep 28, 2019

I reverted the behaviour locally, I'll submit a fix soon

orestisfl added a commit to orestisfl/i3 that referenced this issue Oct 1, 2019
Before 29f2510, tiling windows
confronted to their aspect ratio and the windows were centered in their
container.

This commit re-introduces this logic which is implemented differently
than the logic in floating_check_size.

Fixes i3#3795
@orestisfl orestisfl referenced a pull request that will close this issue Oct 1, 2019
orestisfl added a commit to orestisfl/i3 that referenced this issue Oct 3, 2019
Before 29f2510, tiling windows
confronted to their aspect ratio and the windows were centered in their
container.

This commit re-introduces this logic which is implemented differently
than the logic in floating_check_size.

Fixes i3#3795
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.