On bug 5618 we fixed a bug where we would overwrite the data on the shared framebuffer before the X server had time to finish reading it. Unfortunately that bug papered over a different bug. With the new code you can get a scenario where you have a noticeable latency between your actions and the screen updating. Frame rate is however high so there is some queue building up. You can reproduce it as such: - Use a simple window manager without any fancy compositing - Have a solid colour background - Drag a window around Using the profile chooser is a quick way to test this. If the client is slow then you will get the noticeable lag between the mouse cursor and the window position. The theory is that in this case the update will basically only be CopyRect and fills, which is extremely bandwidth efficient. So the server can cram a whole lot of updates in to the calculated congestion window. The client however requires quite a bit of time to render this update, so the TCP queue starts growing. We need to look over the congestion algorithm and somehow detect and compensate for when the client has sufficient bandwidth, but is failing to keep up for other reasons.
A workaround is restoring DeferUpdate to something better (see bug 5719). Setting it to the previous value of 10 ms seems to get rid of most of the issue for me.
