GNOME Bugzilla – Bug 80509
Improve animations
Last modified: 2007-06-05 02:10:05 UTC
I suggest the animations for shading, minimizing, etc should be disabled by default. (or even removed?). They are to fast to be cool and therfore just disturbing. The only reason to do have animations is to indicate "where the minimized window went" (the animation ends on the tasklist applet if it's running). Opac resize (and opac move) is also quite disturbing.
*** Bug 80510 has been marked as a duplicate of this bug. ***
It's not going to be a preference (neither will resize mode), but the current animations do suck. They just need to be fixed.
I kinda like the current animations, perhaps a tad too slow though. Only too bad there are some animations missing. It would be nice to have similar animations for unshade and uniconify. Or at least uniconify. Perhaps unshade is clear as it is now.
I like the current anims, they are subtle and not disturbing, maybe a little speedup in minimization would be cool. I'd like to have an effect also for appearing windows (just like WindowMaker does).
The shade animation looks much better in CVS now compared to when I repported the bug. Does anyone have a good argument for opaque resize? It does not feel very comfortable on my 500Mhz machine at work... Opaque resize might be good if you work on an image and want to resize the window to match the image size. But that's about the only use I can think of.
The reason for opaque resize is that users see they are manipulating the window directly, and don't have to make an abstract connection between the window and the wireframe.
Animations are not going to be optional? IMHO it'd be nice to be able to turn them off, even if it's just from gconf-editor. Leaving them on by default would be my choice, and if it's a choice between always-on and none at all, I'd totally go for always-on.
Does your opinion have a rationale or is it just a vote. ;-) To make it optional, there has to be a real reason why the setting would depend on the specific user's needs. "The animations are bad" isn't a reason to make it optional, it's a reason to remove them. To argue for an option you need to explain why the problem is inherently impossible to simply get right.
Havoc: I want to live in your binary world, where everything has yes/no answers ;) FWIW, my personal opinion is that the animations give the appearance (to experienced users) of overhead and waste, while not being at all pretty enough to make them impressive for non-experienced users.
I agree on Havoc's arguments for opac resize. But this small usability improvemet has a quite high cost in terms of speed degradation. Even on decent hardware resizing a window (especially one with many widgets) feels laggy and uses a lot of cpu. A majority of the ppl at my office has has opac resize turned off for the above reason.
*** Bug 87793 has been marked as a duplicate of this bug. ***
*** Bug 89074 has been marked as a duplicate of this bug. ***
The animation seems to have been changed somehow (thicker frames?) since around metacity-2.4.0.0.200208061926-0.snap.ximian.1. Is this ongoing work or now considered to be the final stuff?
It's always open to improvement, I think it's better now though. No longer blocks all redraws during the animation, and no animation while shading.
It's great now, just a little bit unsmooth sometimes... But this is probably just X sluggyness, not sure. If X would be cool, I would even ask for a rendering similar to the Nautilus rubberband, but I guess it's not possible to render such a transparent rectangle on top of all windows, right? That would be really awesome.
Transparency isn't possible, no. Ah well.
I think the current behavior is good enough that it can't really be considered buggy; of course it would always be nice to improve, but I don't have concrete ideas until we get some snazzy X server extensions to work with.
The animations are quite nice now. But opac resize should still be an option imho. See my comment at 2002-05-31 for a good reason, or just try it out with an application that has a lots of widgets, or does expensive drawing calculations (waveforms, realtime graphs, etc).
Opaque move/resize is a separate bug, probably closed, in here somewhere. I put a cap on frequency of resize events sent to the app yesterday that may make opaque smoother. That is another case though where it needs fixing not configuring. The whole reason apps are broken is that the programmers of the apps turn on wireframe resize, but then all the users are left screwed because they are still using the default opaque resize.
*** Bug 97094 has been marked as a duplicate of this bug. ***
*** Bug 92867 has been marked as a duplicate of this bug. ***
Pinging. I want a method of disabling the animations that doesn't involve crazy stunts like enabling accessibility mode. Is anyone working on this? Bug #92867 has newer comments than this one.
So let's get this right: you want a GConf key which turns off the minimise animation, etc., without also turning off opaque resize and drag as reduced_resources do. Is that right?
Thomas, look at Bug #92867, I think a global animations toggle for the desktop is probably right for that. Or someone could just fix the animation, don't know why that's so hard to get a patch for...
(In reply to comment #24) > Thomas, look at Bug #92867, I think a global animations toggle for the desktop > is probably right for that. Okay, great. So we turn off the wireframe animations if /desktop/gnome/interface/enable_animations is set, given the provisions you mention in bug 92867 comment 26, and then we can close both these bugs? > Or someone could just fix the animation, don't know why that's so hard to get a > patch for... What needs fixing about it? I thought it was just a human perception problem.
The animation is choppy / too slow / ugly - I think if it were sufficiently well-done nobody would notice it consciously.
(In reply to comment #25) > Okay, great. So we turn off the wireframe animations if > /desktop/gnome/interface/enable_animations is set, given the provisions you > mention in bug 92867 comment 26, and then we can close both these bugs? I want to disable the animation because it is distracting, not because it takes too many resources. Please don't tie this to a global reduced resources mode that would disable other things that I do not want disabled. Apologies if I misread comment 26 and that isn't at all what's going on. :) > What needs fixing about it? I thought it was just a human perception problem. It could be smoother, but I don't think really think there's any way to "fix" it. It's just unnecessary.
(In reply to comment #27) > Apologies if I misread comment 26 and that isn't at all what's going on. :) I meant bug 92867 comment 26, sorry.
Did I say I thought you thought it took too many resources? I didn't mean to.
I think the real fix is to have a compositor; the reason people hate the animation is because the windows below the one being minimized get these ugly black lines drawn on them, which requires those apps below to repaint, which can be slow/choppy/ugly (especially if those apps below the one being minimized are running from a remote machine or the apps are inherently slow at responding to redraw requests or firefox has eaten up all memory again causing all kinds of paging before apps can redraw or do anything else). I'm certain that I can often see 10+ parallel black lines drawn on apps at times before the repainting happens. *shrug* (Though, really, this bug is FIXED and closed; any related issues are for separate bugs as Havoc pointed out.)