maximize using live resize

[Danielle Foré]

instead of maximizing the window with the stretch animation we have now (which can be pretty brutal sometimes), we should take advantage of live resizing for a super smooth transition.

EDIT: if the login animation can be rendered smoothly, with resize and fade, why can't this?
Based on the website, elementary OS runs about as great without graphics acceleration as OS X does without QE/CI.
Just see how Fedora 17 runs without graphics hardware acceleration, but with software acceleration. Not great.

Side note: the Minimize animation feels like it's using a cache, as videos freeze during the animation.

-lordalpha1

[Sergey "Shnatsel" Davidoff (shnatsel)]

I seriously doubt it's worth forcing the app to redraw just for the sake of a smooth transition. Due to rendering being capped to 60fps due to vsync the minimal response time from the app is 1/60=0,017s. GTK apps don't seem redraw that quickly, so that will be one step in 34ms... which is pretty much the maximum time we can afford for a maximization animation.

[Arturo Torres Sánchez (r2d2.art2005)]

If “GTK apps don't seem redraw that quickly”, why not file a bug against GTK asking for smoother redraw?

[Sergey "Shnatsel" Davidoff (shnatsel)]

Because it's not realistic and very much bound to hardware, GPU drivers, etc. We should go filing bugs against GPU drivers that they have ridiculously slow 2D acceleration (except proprietary Nvidia and unstable Intel compiled with SNA), but that's obvious enough already.

[Cassidy James Blaede (cassidyjames)]

I don't know, live resize works reasonably well here. Then again I'm using new hardware.

[Cassidy James Blaede (cassidyjames)]

A possible solution would be similar to OS X's fullscreen animation, which combines a stretch and a fade. I'll try and detail it here:

1. User clicks maximize/fullscreen button.
2. App begins to stretch to maximized/fullscreened size.
3. Compositor figures out what the app is going to look like when it's at the full size.
4. App smoothly fades between the stretched unmaximized image and a stretched fullscreen image while in the middle of the transition.
5. App arrives at proper fullscreen size.

[Tom Beckmann (tombeckmann)]

As shnatsel already said, it will kill performance and I think the current animation is so fast that it's not really visible to the eyes what exactly scales, just that there's a transition between the states.

[ainq (ainq)]

@tombeckmann:
It really does seem jarring and unpolished. Might as well remove the animation altogether, the stretching is ugly, and really pointless since there's no fade.

@cassidyjames: that's the best solution imho

Please reopen this bug, as it really does detract from the elementary experience. How would you feel if the window restore animation, only showed a small, pixelated preview and then suddenly switch to the full size preview, causing a jarring experience?

[ainq (ainq)]

Just another thing, this is VERY noticeable with large screen resolutions (eg. at least 1280x1024).

[ainq (ainq)]

This screenrec shows OS X's resize implementations. The jaggies has to do with some quicktime player recording bugs, but the point is still there.

[Sergey "Shnatsel" Davidoff (shnatsel)]

With the current state of 2D acceleration on Linux under X this is not really viable. Nvidia blob and recent Intel chipsets with the upcoming SNA are the only ones who *might* be able to handle it, and I doubt that because of VSync and compositor delays. In addition, both will redraw on the GPU and compete for its resources, which only makes things worse.

The OS X animation is painfully slow. Given the fact that screen refreshes every 16,(6) ms on 60Hz monitor, while the maximize animation is 150ms, and assuming that the frames get pushed out without any stutter* every two render cycles, we'll get 150 / 16,(6) / 2 - 2 = 2 in-between frames.

Since the purpose of the animation is showing where the window went but being as fast and non-blocking as possible, I'd rather shorten the animation and use a more natural easing mode to compensate for the speed. Overhauilng the whole libmutter rendering pipeline and putting additional strain on the GPU for the sake of Squeezing out a frame or two in the animation isn't worth it IMHO.

* This is a tough problem because rendering is not synchronized with pushing out the final frames and as the window gets larger, it takes more time to render. So the animation can easily stutter by a frame or two, meaning 16ms and 33ms stutter, respectively. Which will look worse than it does now. See http://blog.fishsoup.net/2011/11/08/applicationcompositor-synchronization/ and http://techreport.com/review/21516/inside-the-second-a-new-look-at-game-benchmarking/1 for more details.

[Sergey "Shnatsel" Davidoff (shnatsel)]

Fixing animation is not possible with the current low-level architecture. However, the next-gen architecture is being drafted. See http://www.phoronix.com/scan.php?page=news_item&px=MTE4ODE for details.