Posted on by Martin Flöser

Smooth Window Resizing

As Thomas does not blog and this is quite impressive, I had just to do a video and provide it here. Without further ado I present smooth window resizing with KDE Plasma 4.8:

(Direct Link)

Much Kudos to Thomas for fixing the XSync implementation inside KWin!

68 Replies to “Smooth Window Resizing”

  1. Is there any chance we see this in the KDE 4.7 branch? Obviously, not the pretty Dolphin animations, but the resize fixes only.

    1. unlikely as we have collected quite a lot of changes between master and branch already which makes it difficult to ensure the backported feature is regression free.

  3. Awesome, I’ve been waiting for this since the whole composition thingy got introduced. Thanks a lot 🙂

  4. But this isn’t smooth! It’s as choppy as my KDE 4.7!
    Or my video playback is choppy, which is unlikely, because all the other video I watch is nice and smooth. Or the screen capture was choppy. Anyway, I don’t see it guys.

  5. Really? This is what you’re calling smooth?
    I don’t know… Just take a look at Mac’s file manager, or Windows’s file manager… What the heck, take a look at XP’s file manager! You’ll see that when you resize the window both files and folders get reordered instantly, without waiting for Qt::Mouse_Release event.

    Don’t get me wrong, I’m a proud Arch user since a lot of time (maybe 7 years) and I love KDE, but this just isn’t smooth…

    Anyways, big kudos for the effort, as you’re making a wonderful software!

    1. Actually during resizing the mouse button was not released. So this was Dolphin adjusting itself in a useful way to the size changes. And I think that is the best smoothness you can get with X. Proper fix will only be possible with Wayland.

      1. I know, I know. I know that X is just not coded for what is used right now, but then again, you should consider saying (or not) “smooth” when actually isn’t _that_ smooth.

        But, hey, then again, as I said, you deserve a big kudos for what you’re doing! 😉

        1. what I see there is a better resizing of gimp, but a worse resizing of dolphin with a much less complex UI (no dock widgets). I am not surprised that compiz performs better on gtk while we perform better on Qt.

          In general I would also like to point out that video comparisons are useless, given that they are recorded on different hardware.

          1. >> […] but a worse resizing of dolphin […] ???
            I can literally count the number of repaints when you resizing dolphin.

            1. you are aware of the fact that I use a completely different version of dolphin which only updates the icon view when resizing finished? You noticed that I deliberately stop resizing to show that dolphin does that?

              1. I’m not talking about dolphin’s icons view refreshing (it’s WM independent), but whole window repainting.

                1. no it’s not! It depends on how many size changes are sent to the client. so it completely and only depends on the wm

                    3. Martin, seriously, as long as you cannot see a difference between your video and this one: http://blog.martin-graesslin.com/blog/2011/08/smooth-window-resizing/comment-page-1/#comment-43124 there will be no real progress in the future.

                      Please stop arguing, it is simply embarrassing.

                      Please don’t get me wrong. I love your work and i’m a fan of KDE since ages but such thing like this are making me sad. There are times when you have to accept that you are wrong and it cannot be more obvious then in this case.

                    5. no I’m not. I just tried again and it behaves exactly like in the video – there is only a minor flicker when resizing under heavy load. There is probably room to fine-tune the settings.

                    6. Are you kiddingmartin? This (and yes also the video withdolphin2 is a lot smoother thanthe one withkwin. So it is possible to make it smoother withX. I mean, why are you not able to say, that this works better?

                    7. I am not comparing videos. I will only compare what I see on my system. I will give Compiz a try, but video is not a base for comparison.

                    8. >>I am not comparing videos. I will only compare what I see on my system.

                      Well, here on 5 year old C2D @ 2.2GHz and Nvidia 8600 w/ blop, Compiz resizing isn’t perfect, but Kwin is just bad, very bad, just like on your video.

        2. There’re simply no dock widgets in that dolphin and that’s the expensive part in resizing dolphin. (as is the icon layout, horizontal is faster than vertical for what reason ever)

          No window manager (including compiz) can magically accelerate window resizing but only sync to the client and this way take away stress from it.
          Well, maybe there’s one more thing one can do… 😉

    2. That isn’t the only one pointless and distracting animation in KDE, unfortunately. There are a lot more (and some of them you cannot disable, like animations in Kicker and KRunner, or at least I didn’t find where).

  8. Thiis is about as smooth as it currently is here on my machines, and I don’t find it very smooth. I guess I’ll have to see it live to see if there is any improvement.

  9. Where is the smoothness? I mean, when I present a video or blog with this title, everyone think this is smooth as butter. But this is as “smooth” as on my kde 4.7 system (and no, don’t say that this is impossible, I have two eyes in my head and see things on my system)… I mean, not bad work, but the title is very much over the top.

    Best regards!

  11. I have to agree with the above, this is super choppy! It’s exactly how my poor intel handles compositing, which is the reason I don’t touch KDE. I give every release a try on my laptop, and get disappointed by performance like this every time 🙁

  12. Looks like the trolls are in force on this one.

    Great work. Doing this in the confines of X are I suppose, quite difficult.

    I can’t wait to see how systems will run with Wayland. Now if nVidia would only support it.

  14. Sorry, but, this is way far from smooth.

    gtk2 and gtk3 apps re-size extremely smooth in GNOME 3! qt and kde apps are a bit worse.
    They also re-size fairly smooth in KDE without composition, but act just about how you showed in the video with composition.

    1. The problem seems to be that GTK+ and Qt do not implement the standard in the same way. Which means we can only have one of those perfectly smooth.

  15. Very nice, for too long I have had “display content in resizing windows” turned off because it was so choppy. Thanks.

    Now all you need to do is figure out a way to speed up time until 4.8 is released, and I’ll be really happy.

  16. did a test on my own system to see what you are talking about and I think using the word smooth miss leads people. What I do see is all the flickering from the widgets when re-sizing dolphin are gone, which is plus in my book

    1. yes it might be a problem of definition of “smooth”. to me a window not showing the flickering is smooth.

      1. Very strange definition of “smooth”. “Solid” would be better. Unfortunately, it seems to be buggy. I still can see “escaping” widgets, or it’s screen recorder fault.

        1. yes, these are for me completely gone when I switch to graphicssystem raster for dolphin

            1. no, I don’t think it’s buggy. If at all it’s a configuration fine tuning – it is changed code.

    2. Can you please try this: open dolphin’s settings dialog and close it directly. Then resize the splitter next to the right dock widget.
      Does it still flicker? There was a bug that broke always the “alien widgets”, maybe it got fixed.

      1. when trying your advice it flickers on the right hand side of the widget and not the whole widget. I use kde 4.7 archlinux Nvidia binary driver

  17. While I applaud all efforts in making window resizing smooth, I must agree with other posters and say that this isn’t really smooth at all, I can still see large chunks of the content in the windows being repainted, leaving gray areas shown for split seconds. This is true for me now with 4.7 as well, both on Intel and nVidia graphics. Especially with windows containing complex widget layouts.

    This might not be related to your work on KWin. Perhaps it’s just matter of Qt being slow with layout/painting of the widgets. But I really hope there’s a way to make this smooth for real.

    1. true – I had a look at it, but had problems comparing it. Personal feeling was significant better.

  19. On my system with KDE 4.6 and fglrx driver, what makes HUGE difference is graphicssystem raster. With raster, everything is rendered fast and smooth, even resizing windows.

  20. Many times when resizing the dolphin’s window I use the position of the folders (how many folders are in my view) to decide how far to resize the window, but with the animation from the video I won’t know the folder positions until after I have resized.
    My question is will this animation be configurable?

  21. Ahh martin, he does such a good job in KWIN and gets smashed in the face with “do you call that smooth” comments. Martin, good job!

    However – sorry – it’s not smooth at all. I really do wonder now what the actual difference is in kwin vs compiz and if perhaps Qt has a bug here somewhere..?

    Martin, don’t you have a video of the same on wayland? Or is that not possible yet?

    1. I really do wonder now what the actual difference is in kwin vs compiz and if perhaps Qt has a bug here somewhere..?

      I don’t know – I compared the source code line by line and we do not much different, except that we have a shorter timeout. Also I suspect our decoration to be suboptimal (Compiz has it out of process).

      Martin, don’t you have a video of the same on wayland? Or is that not possible yet?

      No, resizing is not yet implemented on Wayland

        1. surprise, surprise. Xrender compositing is faster than OpenGL on NVIDIA. Tell me something new…

          What I see in the video btw is that shadow is fast, just the window is slow.

          1. >> Xrender compositing is faster than OpenGL on NVIDIA
            Do u known why?

            >>What I see in the video btw is that shadow is fast, just the window is slow.

            Ha, it looks like, but without shadow “window” is painted much faster (without lag).

            Anyway, let’s stick to resizing. Compare that scenarios:
            -with shadows and decorations
            -with decorations and without shadows
            -without decorations (and obviously shadows)

            There will be significantly performance boost with every step.

            1. There are only two scenarios:
              * with decorations
              * without decorations

              The shadows are part of the decoration, so it’s exactly the same. Now you are on NVIDIA, there the decorations are extremely slow. It’s a known issue *shrug*

                  1. Let’s be clear on this. You are telling me, that there is no option for decorations without shadow (when compositing is on)? And it’s the same (with and without shadows)?

                    Are you sure, you wrote the code?
                    ;D

                    1. Do I really have to discuss that? Why do you think you have to enable shadows in the decoration settings? Technically the shadow is implemented in the decoration, so yes it is the same thing.

                    3. Yes you can configure the shadow in the decoration because the shadow is part of the decoration. So it is just the decoration. Turning off the shadow just means a smaller decoration.

                    4. So, it’s painted but not painted? ;D
                      And if there is “no difference” if I see shadows or not, why there is performance difference?

                    5. the difference is only the size of the decoration. Obviously there is a relationship on the NVIDIA blob between the size of the decoration and the performance – this is a known NVIDIA limitation. But yes from the implementation that is the same thing.

                2. The shadow is painted at the same time as the decoration–they are (visually) inseparable. That does not mean that you cannot disable the shadows, just that you won’t have shadows in one position and the decoration in another.

  22. This is indeed much better than before. However, there are still two visible artifacts:
    – there are some gray (non-painted) areas visible when the window is enlarged
    – the resize animation is far from smooth – it appears to be rendering at ~10fps

    The compiz video someone posted appears closer to ~50fps from the looks of it. I think this is caused by the compiz rendering asynchronously, instead of blocking, but it’s been some time since I last looked at the code. It would be interesting to see what compiz 0.9.x has under its sleeves.

Comments are closed.