[regression][nvidia] Dragging windows in expo stutters and is no longer smooth

Comparing profiles from trunk and gles2, it looks like ExpoWindow::glDrawTexture is 120X slower than it used to be. In trunk it uses 0.25% CPU and in gles2 it uses 30%.

Although, that calls back into GLWindow::glDrawTexture, which is where all the CPU is going.

Ignore those comments. The stutter doesn't seem to be CPU-bound. Those major CPU issues are now fixed (by removing glGetBooleanv et al), but this bug (mostly) remains.

I'm not sure what did the trick exactly, but after 2 days of performance fixes this bug appears to be solved now. At revision 3272.

Bug re-opened. This is very noticeable with the nvidia driver. It's jerky with gles2, but smooth with trunk.

It might be related to bug 1025586, or bug 1027863. I'm particularly curious about bug 1027863 because that bug and this are both using new stencilling logic, I think. And historically, stencilling is usually slow.

In fact, using gles2 benchmark reports the frame rate is limited to 30 FPS during expo. If I use trunk then it gets closer to 60 FPS.

OK, disabling stencilling doesn't fix this at all. I'm still suspicious of bug 1025586. Maybe the gles2 branch is affecting/amplifying bug 1025586.

This is very strange but completely reproducible:

1. Slow down the machine, by pinning a CPU core:
while true; do true; done

2. Dragging windows in expo is now smooth again!

3. Stop the processes pinning the CPU in #1 and dragging windows becomes slow and stuttery again.

The workaround in comment #9 does not seem to work for bug 1025586. Although that could just be because LLVMpipe is CPU-bound. But it does seem like this bug is unrelated to bug 1025586 now.

Checked nvidia-settings and powermizer. Even at full performance, dragging windows is still slow. Only the workaround in comment #9 works!?

Perhaps this is the same kind of window movement problem as bug 1025586.

On Fri, 3 Aug 2012, Daniel van Vugt wrote:

> Checked nvidia-settings and powermizer. Even at full performance,
> dragging windows is still slow. Only the workaround in comment #9
> works!?
>
> Perhaps this is the same kind of window movement problem as bug 1025586.
>

If we are still being forced to indirect mode rendering by the fglrx
driver (eg, the compiz/Compiz thing) then this would definitely be an
explanation, as we have to do a lot of stuff synchronously on the server
at the moment to ensure clients are properly updated when updating
windows. This would involve lots of rendering pipeline flushes (eg, an X
pipline flush == a rendering pipeline flush implicitly, so that would
definitely slow down rendering too).

> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is subscribed to Compiz.
> https://bugs.launchpad.net/bugs/1026498
>
> Title:
> [GLES] Dragging windows in expo stutters and is no longer smooth using
> the gles2 branch
>
> Status in Compiz:
> Triaged
>
> Bug description:
> Testing the gles2 branch on the fglrx driver I find dragging windows
> in expo stutters horribly and is not smooth like it is with trunk on
> the same system.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz/+bug/1026498/+subscriptions
>

As per comment #5 this is now just a problem on nvidia.

Downgraded importance to Medium.

Comment #9 shows this bug is not caused by the gles2 rendering being slow. It seems to be an interprocess problem, so likely a race between compiz and Xorg. I still suspect fixing bug 1025586 might solve this.

Seems like r3512 has helped partly to fix this.

However only with an idle desktop. If you've got windows redrawing then the issue persists. But maybe that is better described as bug 1027211.