Shell: Chromium graphics bug

Created on 25 Sep 2020  路  19Comments  路  Source: pop-os/shell

(1) Issue/Bug Description:
After attempting to resize a Chromium window when it is the only window open (e.g. dragging the right side of the window in), toggling window maximization one to three times (with Super-M or by clicking on the maximization icon in the title bar) causes graphical issues, specifically distorting the right and lower parts of the window and causing the window to become unresponsive.

(2) Steps to reproduce (if you know):

  • Open chromium in an empty workspace
  • Attempt to resize the window (i.e. drag one of the sides in or out)
  • Toggle window maximization until bug

(3) Expected behavior:
It shouldn't have graphical issues after toggling window maximization.

(4) Distribution:
Arch

(5) Gnome Shell version:
3.36.6

(6) Pop Shell latest commit:
b65de022e8ddbf91670e0788ebf6178bab873fd2

(7) Where was Pop Shell installed from:
Pop Shell was installed from source.

(8) Monitor Setup (2 x 1080p, 4K, Primary(Horizontal), Secondary(Vertical), etc):
Single 2560x1440 resolution Dell monitor.

(9) Other Installed/Enabled Extensions:
User theme extension was the only other enabled extension. PaperWM and Impatience are installed but disabled.

All 19 comments

This looks similar to another bug I found on material-shell.

This might be an upstream Chromium bug. Does it manifest when PopShell is disabled?

No. In fact, it is not reproducible if tiling is disabled for the window.

Blocked by #481 right now

@mmstick ? I don't understand.

@GeneralPoxter - can you try to replicate this from master_focal? #481 - was merged

I updated my pop shell from master_focal, but the bug persists:
image

I cannot reproduce it on 2 machines one on nvidia and other on intel graphics. And that screenshot does not look good. However, if it is happening on material-shell and pop-shell as mentioned, don't think this is an issue on both extensions.

Is there a journal log you can share with us?

I'm not sure what I should be looking for in the journal logs though...

Mark the time range and look for on the journal. You can start from there.

I've seen it happen before, but it's extremely rare today, if not impossible to replicate on most systems. I do think it's a race condition in Chrome. Perhaps there needs to be a delay between movements of each auto-tile update of a window.

@GeneralPoxter - can you try this branch? https://github.com/jmmaranan/shell/tree/stutter-fix

Unfortunately, that did not fix the issue.

Duplicate of #412

Turning off snap to grid does not seem to fix the issue. The weird graphical tearing doesn't occur, but the chromium window still freezes after a few more min/max toggles.

Snap to Grid is just a variant of tiling for non-tiling floating mode

As referenced in #665, turning off Smart Gaps seems to do the trick, but a brief flicker of a corrupted chromium window is still visible.

This bug can no longer be reproduced on my system as of Version 1.1 (possibly earlier), even with Smart Gaps turned on.

Was this page helpful?
0 / 5 - 0 ratings