That was a design decision (made by developers, didn't actually go through the design team).
First we were ignoring the mir surface size when resizing, so if it didn't match or lagged behind the QML window size, the surface would get stretched or squeezed to fit inside it.
Now the QML window size *always* match the Mir surface size. So the resize "animation" will be as smoothly as the client application is able to redraw its mir surface.
I think we need design input on how the window resize UX should look like. Ie, how to deal with applications that are slow to relayout/redraw and still have a smoothly "resize animation". Should we display some sort of size hint such as that translucent orange rectangle in Unity 7?
That was a design decision (made by developers, didn't actually go through the design team).
First we were ignoring the mir surface size when resizing, so if it didn't match or lagged behind the QML window size, the surface would get stretched or squeezed to fit inside it.
Now the QML window size *always* match the Mir surface size. So the resize "animation" will be as smoothly as the client application is able to redraw its mir surface.
I think we need design input on how the window resize UX should look like. Ie, how to deal with applications that are slow to relayout/redraw and still have a smoothly "resize animation". Should we display some sort of size hint such as that translucent orange rectangle in Unity 7?