GNOME Bugzilla – Bug 102175
improve minimize animation
Last modified: 2006-04-25 18:03:15 UTC
Three things need to be done to improve the metacity minimize animation. 1. Speed it up and make it smoother. 2. Make the lines thiner. 3. The window should be drawn after not before the animation is drawn. I'm going to attach a patch that addresses the first two items. I changes to using the DRAW_ROOT animation which has none of the smoothness problems of the current animation. It also speeds up the animation. The problem with the DRAW_ROOT animation is that the area behind the window isn't redrawn until after the animation. This is not a problem once number 3 is implemented bacause the window is redrawn after the animation. Windows and Enlightement both undraw the window after the animation and it looks a lot better and smoother and snappier. Unfortuantely I was not able to work out how to implement 3 so that still needs to be done.
Created attachment 13266 [details] [review] metacity animation patch
One thing we might consider is using Xcursor for this, I don't know how well or whether it would work.
*** Bug 105965 has been marked as a duplicate of this bug. ***
There's a reduced_resources flag we're about to land on HEAD that disables the animation. I think the current animation is fine for now, it's kind of a tossup with XOR. When we get some nice new X server features, we can finally make it not suck. It's possible investigating E and other WMs someone could come up with something fancy too.
The compositing manager in metacity CVS now (--enable-compositor) and the composite extension in the upcoming X.org release (in rawhide now, enable "Composite" extension in xorg.conf) should be sufficient to work on a better animation, though for now it will be really slow.
Would it be possible to create a new flag "disable_min_anim" out of the "reduced_resources" flag ? Some people don't like such animations but don't want to lose all the effects (like showing the content of windows when moved). Should I create a fill a new bug report for this request ?
I don't want a billion little nitpicky settings for every possible effect and feedback. There's some sort of desktop-global "disable animations" flag we could key off of, maybe. But the most important thing by far is to just make the animation nice.
I have been working on a new minimize animation that animates by using the windows titlebar. Would such an animation be better than the current one? I think it would for a few reasons: 1. MS Windows and many other desktop environments minimize by animating the titlebar so it makes sense to do it that way since it is the "standard way". 2. It makes it easier to make a good-looking unminimize animation by just playing the animation backwards. I don't think it would look very good with the black rectangles Metacity uses. 3. The black rectangles aren't visible on a dark background. 4. I think many users doesn't like how the current animation looks. The patch works (for me) like I want it, but I think it is very "hackishly" implemented and I would be very happy if someone can answer some questions so I can implement it right. :) 1. What is the deal with BoxAnimationContext? It contains three different code paths for three different animation styles, DRAW_ROOT, WIREFRAME and OPAQUE, but only WIREFRAME is used which fallbacks on DRAW_ROOT if the Shape-extension isn't availible. The plan must have been to use BoxAnimationContext for lots of different types of animations right? There are some code inside #if 0's that seem to call it. 2. The OPAQUE animation doesn't work correctly. In a comment it says "doesn't look quite right due to the mapping and unmapping of windows that's going on". What does that mean? It seems like the code isn't able to take a snapshot of the window that is about to be minimized UNLESS there is no other window than the desktop behind it. How come? I found that if you call implement_showing() from meta_window_minize(), you will always get a correct snapshot. I doubt that is the correct way to do it, but there has to be a way to do it before the unmaps.
Created attachment 52605 [details] [review] This patch implement a minimize animation using the titlebar
This is not an answer to your questions, but I still think it's very necessary to give the possibility to users to disable any animations without the disadvantage of the "reduced_resources" flag. Björn> Does your patch fixes the problem of the actual animation that the area behind the window isn't redrawn until after the animation ? This the main bug of the actual animation (but of course, a better animation could be even better).
I'm note sure I understand what you mean. DRAW_ROOT has the problem that the area isn't redrawn (maybe because Metacity grabs the XServer and doesn't release it before the animation is done?), but the only way to see that is to not have the Shape extension. By default Metacity selects DRAW_WIREFRAME and fallbacks to draw DRAW_ROOT if Shape isn't availible. My patch uses a DRAW_OPAQUE animation style which doesn't have that problem because it is not dependant on Shape. So I guess you could say it solved the problem, but only because it bypasses it.
The new patch and the files below are my work so far at implementing better animations. Currently, its features are minimize and unminimize. I intend to extend it to cover maximize and unmaximize too. There are some graphics bugs in it because it relies on meta_gdk_pixbuf_get_from_window to take an image of the titlebar which doesn't work if the titlebar hasn't been shown or is occluded. Otherwise the code seem to work and is much more cleanly implemented than the previous patch. However, it required very drastic changes to stuff in window.c.
Created attachment 52730 [details] [review] part of my implementation for titlebar un/minimize animations
Created attachment 52731 [details] new animation-framework
Created attachment 52732 [details] header file
A "disable minimize animation" flag for metacity is most definatley needed.
Disable resources gets rid of the unsightly wireframe minimization animation, but then creates an EQUALLY unsightly mess of having wireframes whenever I drag the window. So our choice is wireframes when minimizing, or wireframes when moving? Hello, is this hell? Please give us an option HP, call it:"not forced to see wireframes ever again", or call it "heaven" if thats already taken.
I'd be very happy to see a patch that replaced the wireframes with a better animation, I think I've said many times.
Comment on attachment 52730 [details] [review] part of my implementation for titlebar un/minimize animations This looks about right to me, it could probably use some cleanup... e.g. if there's unused cruft in effects.c after this it should go away ... also Elijah you should probably look at and test out the changes to the calc_showing/implement_showing/etc. code since that can definitely break things. I'm looking at the patch here and not animation.c, but one thing I just thought of is to be sure the titlebar-snapshot code is handling windows with no frame
Will any near future release support disabling the minimize animation from a gconf key? I use xcompmgr, and metacity is the only thing left leaving random trails. I am aware that it will improve, but in the meantime, having an option to disable it would be very much appreciated. I'll be watching this bug report ;)
There's some off-topic comments here (e.g. 10, 16, 17, 20), and a patch that is potentially for the non-composite case, _but_ I think the thrust of this bug is composite related so I'm reassigning there. Might be a dupe of some sort or not worthwhile as a bug since we don't need one to remember we want to work on that (in which case it could be assigned back for the non-composite case or something), but I'll let Soeren decide.
*** Bug 334432 has been marked as a duplicate of this bug. ***
I don't think this is useful as a compositor bug, so I'll just close it.