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

Animations glitch on overview #347

Closed
matiasnbella opened this issue Oct 28, 2020 · 26 comments · Fixed by #502
Closed

Animations glitch on overview #347

matiasnbella opened this issue Oct 28, 2020 · 26 comments · Fixed by #502
Labels
visual-bug Minor visual inconsistency etc.

Comments

@matiasnbella
Copy link

Happening since updating to gnome 3.38.
OS: Fedora 33
Using latest release.
2020-10-28-13-03-54

@matiasnbella matiasnbella changed the title Animations grlitch on overview Animations glitch on overview Oct 28, 2020
@azmeuk
Copy link

azmeuk commented Oct 29, 2020

I can confirm this too with Archlinux.

@hedning
Copy link
Member

hedning commented Oct 29, 2020

Yeah, upstream did a fairly substantial rewrite of the overview layout code in 3.38 which I haven't had the time to monkey patch correctly yet.

@ejemba
Copy link

ejemba commented Nov 9, 2020

@hedning Do you think you can work on the rewrite because basically now nothin is working properly under Archlinux :'(

Or should I rollback my version of gnome shell ?

@hedning
Copy link
Member

hedning commented Nov 9, 2020

@ejemba I'm on 3.38 now, so will hopefully get the time/motivation to fix things.

In the meantime I'd double check that you've turned only-scratch-in-overview. Should look like this in paperwm-preference (if you're on develop):
image

@hedning
Copy link
Member

hedning commented Nov 9, 2020

OK, pushed 261ae9d, which should hopefully make things usable.

@ejemba
Copy link

ejemba commented Nov 9, 2020

@hedning I just pull your commit and refresh my gnome-shell
I have the same scratch configuration than you.
It's strange if I have at least one window that is in fullscreen, the overview screen bugs.
If I reduce this same windows by lets say 200pixels then the overview is working again.

@ejemba
Copy link

ejemba commented Nov 10, 2020

Always got the glitch in function of the disposition of the windows (cf previous message)
here are my error messages

.. gnome-shell[1079]: Can't update stage views actor overviewGroup is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overviewGroup is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overviewGroup is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overviewGroup is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overviewGroup is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overviewGroup is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overviewGroup is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overviewGroup is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor overviewGroup is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor Gjs_ui_workspacesView_WorkspacesView is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor Gjs_ui_workspace_Workspace is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor Gjs_ui_windowPreview_WindowPreview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor StBin is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor StIcon is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor ClutterActor is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor Gjs_ui_windowPreview_WindowPreview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor StBin is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor StIcon is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor ClutterActor is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor Gjs_ui_windowPreview_WindowPreview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor StBin is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor StIcon is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor ClutterActor is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor Gjs_ui_windowPreview_WindowPreview is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor StBin is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor StIcon is on because it needs an allocation.
.. gnome-shell[1079]: Can't update stage views actor ClutterActor is on because it needs an allocation.

@hedning
Copy link
Member

hedning commented Nov 14, 2020

@ejemba Looks like you're hitting the old code, you'll need to restart gnome-shell for changes to extensions to take effect.

@hedning
Copy link
Member

hedning commented Nov 17, 2020

Working on overview fixes here: https://github.com/paperwm/PaperWM/tree/3.38-overview-fixes

Some bugs remaining, but it's usable on my machine as far as I can tell.

@ejemba
Copy link

ejemba commented Nov 18, 2020

@hedning Thank you, because my overview is broken ...

@hedning
Copy link
Member

hedning commented Nov 22, 2020

Fixed window sorting in the overview on develop (ie. windows are now sorted in tiling order again). Haven't quite figured out how the animation is now done, so selecting a window not already in the viewport will still result in wonky animation.

@ejemba
Copy link

ejemba commented Dec 4, 2020

@hedning FYI, updating metadata.json with the good gnome-shell version fix the problem for me

diff --git a/metadata.json b/metadata.json
index 142692d..4074038 100644
--- a/metadata.json
+++ b/metadata.json
@@ -4,6 +4,6 @@
   "description": "Tiling window manager with a twist",
   "url": "https://github.com/paperwm/PaperWM",
   "settings-schema": "org.gnome.Shell.Extensions.PaperWM",
-  "shell-version": [ "3.28", "3.30", "3.32", "3.34", "3.36"],
+  "shell-version": [ "3.28", "3.30", "3.32", "3.34", "3.36", "3.38" ],
   "version": "38.0"
 }

I can not explain why but no problem even if with 4 windows in fullscreen

@hedning
Copy link
Member

hedning commented Dec 5, 2020

Pushed fix for the metadata problem. I'm guessing you had an old PaperWM version installed through eg. the arch package, which was then loaded instead of the git version (though a bit weird why it wouldn't prefer the newer extension version...), adding explicit 3.38 support in the metadata then made gnome-shell prefer the newer version.

@ejemba
Copy link

ejemba commented Dec 5, 2020

I do not understand why you're saying I might have an old version because I'm getting it from github and git pull'ing each time and I am on the develop branch :) I do not use the Arch AUR Package.

@hedning
Copy link
Member

hedning commented Dec 5, 2020

Ah, right, it was just a guess based on the fact that changing the metadata info seemed to fix things.

@hedning hedning added the visual-bug Minor visual inconsistency etc. label Jan 16, 2021
@paradajz
Copy link
Contributor

Any chance of an upcoming fix for this? Not too important but really janky, and as the OP said, it's been happening since 3.38.

@jtaala
Copy link
Collaborator

jtaala commented Mar 28, 2023

I can't quite tell from the video what glitch this is referring to (was it the pdf viewer in the video?).

I haven't experienced this issue (i.e. I can't reproduce). @paradajz can you let me know what branch you're on (you can just run the gather-system-info.sh script if you're on a recent develop commit), and give me any tips on how to reproduce this.

@paradajz
Copy link
Contributor

@jtaala I've tried your redux fork and this is still happening. The issue is that the animation is glitchy when you select an window in overview which isn't fully shown currently on the screen. So if you have something like this, where each w is a window, and | is an actual screen border:

w1 | w2 w3 w4 | w5

Selecting w2, w3 or w4 in overview results in normal animation. Going to overview and selecting either w1 or w5 will result in somewhat broken animation. I'm attaching the video. Notice that when I select settings window which isn't fully visible on the screen in overview, the animation is somewhat wonky. Like it starts zooming in on the app correctly but then near the end it just jumps in place.

Screencast.from.2023-03-29.08-31-26.webm

@jtaala
Copy link
Collaborator

jtaala commented Mar 29, 2023

@jtaala I've tried your redux fork and this is still happening. The issue is that the animation is glitchy when you select an window in overview which isn't fully shown currently on the screen. So if you have something like this, where each w is a window, and | is an actual screen border:

w1 | w2 w3 w4 | w5

Selecting w2, w3 or w4 in overview results in normal animation. Going to overview and selecting either w1 or w5 will result in somewhat broken animation. I'm attaching the video. Notice that when I select settings window which isn't fully visible on the screen in overview, the animation is somewhat wonky. Like it starts zooming in on the app correctly but then near the end it just jumps in place.

Thanks @paradajz!

I think I understand - tell me, are you using multiple monitors (e.g. the | is an actual monitor?). I think something similar was alluded to here: #413 (comment).

I don't usually use multiple monitors (or overview very much for that matter) - anyone that uses / sees this want to have a go at digging into this more? (debugging etc.).

@paradajz
Copy link
Contributor

No, I'm using a single monitor (widescreen if it matters).

e.g. the | is an actual monitor?

Yes.

@jtaala
Copy link
Collaborator

jtaala commented Mar 29, 2023

Thanks @paradajz I see, I'm not quite seeing (I think) what you're seeing(?). Here's what I see with overview (you're window layout looks quite different than mine - likely the widescreen thing?):

paperwm-overview-glitches.mp4

I do see the snapping though (not smooth moving to after window is selected).

@paradajz
Copy link
Contributor

I do see the snapping though (not smooth moving to after window is selected).

Yeah, that's exactly the issue. :)

@jtaala
Copy link
Collaborator

jtaala commented Mar 29, 2023

I do see the snapping though (not smooth moving to after window is selected).

Yeah, that's exactly the issue. :)

Ah, gotcha! Sorry, kept seeing some weird (well, what I thought was weird) stuff in the video. Yep, I see the snapping. Thanks for the patience!

@Lythenas
Copy link
Collaborator

Maybe to summarize: When selecting a window in the overview that is currently not fully visible in the workspace, the overview will close (with animation) but then the selected window will snap into place instead of smoothly animating.

My guess is that the animation happens, but we don't see it because of the gnome overview close animation.

@jtaala
Copy link
Collaborator

jtaala commented Mar 29, 2023

My guess is that the animation happens, but we don't see it because of the gnome overview close animation

Good point - although I just set animation_time to something ridiculous like 10.0 (which is crazy slow) and I'd expect to see some type of animation for moving to the select window - but it still just snaps instead... so might be something else going on here. Will try dig into it a bit more.

@jtaala
Copy link
Collaborator

jtaala commented Mar 31, 2023

@paradajz, finally found the issue. @Lythenas was right (about animation during overview). Turns out focus_handler was being actioned during overview (when you select a window) and executing (or trying to) ensureViewport (which moves the view to the selected window). #502 fixes this.

If you're still on PaperWM-redux, can just do a git pull and restart gnome, otherwise hopefully this PR will be merged soon.

Quick vid of new behaviour:

paperwm-overview-glitches-fix.mp4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
visual-bug Minor visual inconsistency etc.
Projects
None yet
7 participants