[0.9.8 r3110 regression] [LLVMpipe] Dragging windows around is much slower with compiz 0.9.8 than 0.9.7 (using LLVMpipe)

[Daniel van Vugt]

Using LLVMpipe, compiz renders fairly quickly using 0.9.7 (and forcing swap buffers on) and dragging windows is reasonably smooth. However in the current source for 0.9.8 (lp:compiz), dragging windows around is now very slow and laggy.

I suspect the cause of this regression is:
https://code.launchpad.net/~smspillaz/compiz-core/compiz-core.work_923683/+merge/102687

[Daniel van Vugt (vanvugt)]

Confirmed. I just ran r3109 and r3110 under LLVMpipe and the difference is night and day. This regression came from r3110.

[Daniel van Vugt (vanvugt)]

Narrowed the problem down to just core and the move plugin. Loading no plugins other than "move", I find:
    r3109: Is slow for a few seconds, then becomes very fast and smooth.
    r3110: Is always slow and laggy.

Theory #1:
There could be a feedback loop in our window configure handling, such that receiving ConfigureNotify causes us to reconfigure the window again.

Theory #2:
We have a geometry/serverGeometry logic problem, resulting in a difference somewhere between the two that is never quite resolved.

Theory #3:
The move plugin is misusing geometry/serverGeometry causing movements to not be smooth.

Theory #4:
pointerX/Y or lastPointerX/Y updates are lagging. Seems unlikely now I've tried switching the move plugin to XQueryPointer and the problem remained.

[Daniel van Vugt (vanvugt)]

Actually, this sounds a bit like bug 866752.

[Sam Spilsbury (smspillaz)]

> There could be a feedback loop in our window configure handling, such that receiving ConfigureNotify causes us to reconfigure the window again.

Sounds plausible.

>Theory #2:
> We have a geometry/serverGeometry logic problem, resulting in a difference somewhere between the two that is never quite > resolved.

> Theory #3:
> The move plugin is misusing geometry/serverGeometry causing movements to not be smooth.

serverGeometry/geometry now return the same thing, so unlikely.

[Sam Spilsbury (smspillaz)]

I did notice just now that we're probably calling through to sendConfigureNotify a lot more often than we are normally now, which involves a lot of X11 pipeline flushing (eg, have to call XSync to get the server side positions etc). It is probably safe to call sendConfigureNotify to update clients as to their position when we receive the new position from the server.

It doesn't exactly explain why we're slow on llvmpipe, unless llvmpipe is always indirect-rendered, in which case, yes, it would be slower.

[Daniel van Vugt (vanvugt)]

I was already comparing LLVMpipe with LLVMpipe. The difference is lp:compiz revision 3110 (slow) compared to 3109 (fast). Both running on LLVMpipe.

I tried it all again today, to make sure I wasn't imagining things. Today I still find that r3109 is dramatically faster than r3110.

[Daniel van Vugt (vanvugt)]

But I will check out sendConfigureNotify later, thanks.

[Daniel van Vugt (vanvugt)]

It seems highly likely that a fix for this bug will help the Nexus 7 too.

[Sean Feole (sfeole)]

Daniel ,

What would be the simplest way to test this on the nexus 7.
So a user would be able to see the speed difference from 0.9.7 vs 0.9.8

[Daniel van Vugt (vanvugt)]

Sean,

On the Nexus 7 it's really about how slow window movement is, and how high the Xorg/compiz CPU it triggers. I have not confirmed this bug is a major factor on the Nexus 7 but it seems highly likely. No, sorry but there's no way to test the old 0.9.7 behaviour on Nexus. 0.9.7 did not have (adequate) working ARM support.

[Alex Heusingfeld (aheusingfeld)]

Is there a way to test the above mentioned compiz milestone 0.9.9.0? The ubuntu-nexus7 ppa doesn't provide it, yet. Thanks in advance.

[Daniel van Vugt (vanvugt)]

The bug is not fixed anywhere yet. There's nothing to test.

[Danial Bulloch (dbulloch)]

I noticed today that I did not have this issue. It started for me(as far as I can tell) on install of 12.10, but seems to have been fixed or in some other way relieved in the past week. After a restart and a standby the issue still does not show it's head.