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

Bug #1025586 reported by Daniel van Vugt on 2012-07-17
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Compiz
High
Unassigned
Ubutter
Undecided
Unassigned
ubuntu-nexus7
Undecided
Unassigned
compiz (Ubuntu)
High
Unassigned

Bug Description

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

summary: - LLVMpipe: Dragging windows around is much slower with compiz 0.9.8 than
- 0.9.7 (using LLVMpipe)
+ [regression] [LLVMpipe] Dragging windows around is much slower with
+ compiz 0.9.8 than 0.9.7 (using LLVMpipe)
Daniel van Vugt (vanvugt) wrote :

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

summary: - [regression] [LLVMpipe] Dragging windows around is much slower with
- compiz 0.9.8 than 0.9.7 (using LLVMpipe)
+ [0.9.8 r3110 regression] [LLVMpipe] Dragging windows around is much
+ slower with compiz 0.9.8 than 0.9.7 (using LLVMpipe)
tags: added: compiz-r3110-regression
Daniel van Vugt (vanvugt) wrote :

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.

Changed in ubutter:
status: New → Triaged
Daniel van Vugt (vanvugt) wrote :

Actually, this sounds a bit like bug 866752.

Changed in compiz:
assignee: Daniel van Vugt (vanvugt) → nobody
Sam Spilsbury (smspillaz) wrote :

> 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) wrote :

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) wrote :

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) wrote :

But I will check out sendConfigureNotify later, thanks.

Changed in compiz:
assignee: nobody → Sam Spilsbury (smspillaz)
Changed in compiz:
milestone: 0.9.8.0 → 0.9.8.1
Changed in compiz:
milestone: 0.9.8.2 → 0.9.8.4
Changed in compiz:
milestone: 0.9.8.4 → 0.9.9.0
Daniel van Vugt (vanvugt) wrote :

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

Changed in compiz (Ubuntu):
importance: Undecided → High
status: New → Triaged
Changed in compiz:
assignee: Sam Spilsbury (smspillaz) → Daniel van Vugt (vanvugt)
Sean Feole (sfeole) wrote :

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

Changed in ubuntu-nexus7:
status: New → Confirmed
Daniel van Vugt (vanvugt) wrote :

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.

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) wrote :

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

Danial Bulloch (dbulloch) wrote :

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.

Changed in compiz:
milestone: 0.9.9.0 → 0.9.9.2
Changed in compiz:
milestone: 0.9.9.2 → 0.9.10.0
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in compiz:
milestone: 0.9.10.0 → 0.9.10.2
MC Return (mc-return) on 2013-07-24
Changed in compiz:
milestone: 0.9.10.2 → 0.9.11.0
Changed in compiz:
status: Triaged → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers