[regression] All apps have a lower frame rate under Unity.

I also see exactly the same behavior with Oneiric's Compiz and Radeon HD 3200 (AMD 780G chipset's integrated graphics). Compiz is a lot slower/laggier than it was in 11.04.

Testing with glxgears (leaving the glxgears window in its default size) on latest Ubuntu 11.10:

Compiz is at around 33-42 FPS
Mutter is at a stable 59.xxx FPS

Ubuntu's 11.04 Compiz was also at 59.xxx FPS (the screen's refresh is at 60 fps).

There is a chance that the fix in:

https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/763005

solves it, but i don't have a way to test it until a PPA of the fix for Oneiric is build.

I think that this is a very important regression because for the systems that it affects, Compiz/Unity becomes unbearably stuttery/slow.

Status changed to 'Confirmed' because the bug affects multiple users.

I looked at #763005, and that bug indicates it's a problem in compiz's sync-to-vblank implementation. Changing that setting makes no appreciable difference for me, though.

Yes indeed, that setting doesn't make a difference for me too. I have also tried a number of other solutions (like changing SwapbuffersWait in xorg.conf) that also didn't work.

Based on the above, IMHO, i believe that the problem is something that changed inside compiz between Ubuntu 11.04 and 11.10.

Yes indeed, and moreover the problem is due to a very recent change in compiz. I only discovered glxspheres a couple of weeks ago, and when I first ran it I was getting 59.xxx fps with the (beta 1) Oneiric version of compiz.

I disabled DynamicTwinView in the Xorg configuration file, disabled Compiz refresh rate detection, and i did set it manually to the real refresh rate (60fps).
The bug is still not fixed : I'm still getting half the fps i have in Gnome Shell and Unity 2D.

On my nvidia 8400m GS GPU, that makes almost any game unplayable under Unity 3D desktop (including Trine, Minecraft and others), as long as this graphics card is just powerful enough to get these games running around 60~70fps under normal circumstances.

After my system updated to compiz 1:0.9.6+bzr20110929-0ubuntu1 and unity 4.20.0-0ubuntu1 I'm now getting just under 60 fps with glxspheres again on my Intel chipset (and 110 fps on the nvidia chipset), so for me it is fixed now.

Or at least it's mostly fixed. Immediately after logging in, I get 59.x fps in glxspheres: after unity crashes and restarts, I might get 30-35 fps again.

Same here, good performance right after startup, but it slows down (probably after suspend and resume, or VT switch, or when a game exits). I might have to run some more tests, to identify precisely what causes performance drop.

I had to run "unity --reset" to fix a bug in the way it was handling windows, and now the performance is back to being woeful.

Same here about performance in 3D applications like games or 3D-accel-programs.
What helped out a good way was to activate the "unredirect fullscreen windows" checkbox in CCSM under "Composite".

Since that I can run glxsphere in good stable rates, I also can play OilRush in average FPS. Before that, OilRush was about 5 to 12 FPS.

Running Ubuntu 11.10 with Unity on an Acer Aspire 8920 with NV 9500M GS.

I already have "unredirect fullscreen windows" checked (but I don't think should affect glxspheres in any case since it isn't a fullscreen window).

After a complete system reboot I can sometimes get ~60 fps in glxspheres. But it gradually (or some cases, suddenly) regresses.

I have noticed that when it runs slower, both glxspheres and compiz take up less CPU time:

60 fps => glxspheres = 20% CPU / compiz = 14%
45 fps => 16% / 11%
40 fps => 11% / 8 %

ie compiz has decided for some reason to work less hard, resulting in laggy 3d.

It sometimes goes back to 60 fps all by itself without a reboot. For instance, just now I checked 'Detect Refresh Rate' in ccsm/General Options and it went from 40 back to 60. (I had tried setting the refresh rate to 60 Hz in case the detection code was faulty, but I can't say that it made any difference.)

I'm glad I found this post. I'm experiencing the same problem on three different machines running Ubuntu 11.10:

1. a Sony Vaio VPC F11S1E (GeForce GT330M),
2. a generic AMD A8 Fusion box with a GeForce GTX460, and
3. an iMac (2009 model) with a GeForce 9400.

The symptoms are: from start, things are buttery smooth. Then, if I open Firefox things are still buttery smooth for a short time, then everything becomes laggy and jerky.

All three machines were running 11.04 and did not experience this problem.

Compiz performance deteriorates with usage.

Thank you for taking the time to report this bug and helping to make Ubuntu better.

As these performance issues are often specific to a graphics driver, we should initially focus on the graphics hardware this bug was reported on: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller

The intel graphics driver documentation suggests this might be caused by the TripleBuffer configuration option which is enabled according to your log files. It is in fact enabled on all intel graphics systems by default.

It's possible and even likely that compiz in Ubuntu 11.10 is taking slightly more time per frame than 11.04 did, and so is not meeting the deadline to achieve full frame rate. I suspected this was happening on my machine a few days ago (with the same hardware) after I upgraded to 11.10.

Please try disabling TripleBuffer by setting (something like) this in /etc/X11/xorg.conf:

       Section "Device"
         Identifier "devname"
         Driver "intel"
         Option "TripleBuffer" "false"
       EndSection

If that fails, please also try adding:

         Option "SwapbuffersWait" "false"

For more information, run: man intel

If the above options fail to improve anything, please attach new copies of your /var/log/Xorg.0.log file when the options are set.

Finally, your logs show that you have not yet upgraded to the latest compiz 0.9.6+ which comes with Ubuntu 11.10. Please try upgrading your packages/system to match the final version of compiz that was released in Ubuntu 11.10.

You will probably also need to turn off "Sync To VBlank" in compiz before you can test if TripleBuffer=false is fixing the problem.

To turn off "Sync To VBlank", please install the package "compizconfig-settings-manager", run "ccsm" and turn it off in the OpenGL section.

AMD/ATI and Intel users: Please check if you have bug 763005 before thinking you have this one.

NVIDIA users: Please try the workaround in bug 92599 first.

Nvidia here. All workarounds in bug 92599 did not work.

Intel here: Bug #763005 isn't a problem (the animation is fast and smooth whether or not glxspheres shows low frame rates) and Option "TripleBuffer" "false" (with or without sync to vblank) doesn't fix it.

The low frame rates aren't consistent. Often (well, usually) immediately after X starts, glxspheres can manage almost 60fps. Some time later it deteriorates. I've seen the frame rate go as low as 20fps. Sometimes it recovers by itself, other times not.

Right now, glxspheres is showing between 24 and 35 fps. The system isn't under heavy load or anything - I've only got firefox running. And as a comparison, alien arena is showing 8-15fps whereas normally it can manage closer to 30fps.

Here's Xorg.0.log for the currently slow-running system. TripleBuffers is turned off, but SwapBuffers wait is enabled.

And compiz is currently at version 0.9.6+bzr20110929-0ubuntu5.

I think it is worth trying the fix I proposed for bug 763005. Even if you don't have the symptoms of that bug, you will in theory still get a compiz performance boost from the fix. Whether or not the improvement is noticeable for you remains to be seen.

You can try the fix by adding ppa:vanvugt/compiz to your package sources;
https://launchpad.net/~vanvugt/+archive/compiz

I added the ppa and have been using it for a few days. I have observed that there is no performance boost from my desktop effects. Actual gaming, I don't know.

I have also tried all vsync fiddling, triple buffering settings, etc. etc.

Long story short: Performance is awesome after boot. Just dandy.

Seven hours later I'm watching a powerpoint presentation when I move my windows around.

Performance degrading slowly over time could be a resource leak of some sort.

If you find performance gets worse over time, try noting how much memory compiz is using when you first log in and compare it to when performance has degraded. You can get the memory usage from:

  ps auxw | grep compiz

The columns of interest are #5 and #6 (VSZ, RSS).

I'll do that. Is this the correct bug report to go on? There are so many bug reports that I'm not sure which one to really post to. Performance is just fine at first but becomes unbearable after many hours. And this is on a higher-end machine (gtx 560, 8 gb ram, etc.)

@Chauncellor, I'm not sure if this is the right bug for you, but I can't suggest a more appropriate one either. Certainly the reporter of this bug describes similar performance degradation to yours.

Video performance bugs are very messy. Unless there is an easy switch or workaround to try then most of the time you'll never be too sure that everyone is actually experiencing and discussing the same bug. But I am trying to (slowly) disambiguate such bugs, and fix some of them too.

I have some more observations:

1. I tried gnome-shell for a day, and at one point glxspheres was suffering in performance, but not as badly as under compiz. The animation was periodically freezing for a half second - it would then report one (say) 40fps reading, and then immediately jump back to 59fps. I didn't notice any slowdown in the UI, though.

2. Today in compiz I had the slow window dragging issue after a few hours of use, ie when you drag a window it only moves the window jerkily, and if you move the mouse too fast the window stops moving altogether. However, and perhaps strangely, glxpheres reported a consistent 59fps. Animations were slower than usual although the super-S and super-W animations were still nice and fast.

The only odd thing that had happened in the session was that compiz had earlier lost track of a window while I was dragging it when another window was opened - I had to manually kill the process and restart it because compiz couldn't re-display it.

I tried a ps auxw |grep compiz and it reported 721 MB VSZ and 71MB RSS, whereas after startup it's more like 800MB and 120MB.

I'll try the PPA version to see if it helps.

Almost a day later the PPA version of compiz is still performing nicely even after a few suspend/resume cycles (this is on an Intel GPU). I haven't noticed any UI slowdowns and the slowest that glxspheres has shown is 58fps.

There have been a couple of issues, which may not be related:

* Unity crashed once and restarted when I tried to open a window in Thunderbird. Afterwards I had to restart Thunderbird because it just displayed as a large empty frame with the background showing through. compiz does generally have trouble with Thunderbird, though.

* The adjust screen brightness buttons stopped working after a suspend/resume.

* A couple of times the screensaver has kicked in while I was typing (it immediately stopped when I hit the next key).

If you ever want to revert to the original compiz version, you could try a script like the one I use. Something like this:

sudo apt-get install compiz/oneiric compiz-core/oneiric compiz-gnome/oneiric compiz-plugins/oneiric libdecoration0/oneiric libdecoration0-dev/oneiric

Rocko, after you have established the bug has gone away, please try reverting to the original version of compiz and see if it comes back. If it does come back reliably without my PPA fix then it will be safe to mark this as a duplicate of bug 763005.

OK, I'll keep testing the PPA version for a while first.

With the PPA version, I did encounter the 'jerky' animation while moving windows problem again, ie where you move the mouse but the window only moves every twenty pixels or so of mouse movement (and sometimes it will freeze and wait until you stop moving the mouse before it moves the window). Is that likely to be a different bug? compiz wasn't using a lot of memory at the time and glxspheres still showed 57-59fps, so that was fine.. I opened ccsm and turned off session management, which crashed compiz (as ccsm often does), and when it restarted moving windows was smooth again.

Is there anything I can check that might be useful when I encounter the 'jerky' windows movement again?

I believe the jerky window moving problem is a bug in unity-window-decorator. That's my suspicion anyway. I noticed the same bug, but it too vanished mysteriously after a while and hasn't come back for many days.

Someone has probably already logged that bug elsewhere if you care to dig deep enough to find it.

I've set a cron job to log ps auxw every hour. It hasn't gotten to intolerable proportions yet, so I'll wait until reporting that. However, I have noticed the VSZ and RSS columns moving upward.

I installed the 285 and 290 (beta) drivers, but the problem persists in 11.10.

I did a fresh install (and applied all updates) to Ubuntu 11.04 and no longer suffer from this problem.

I'm going to stick to 11.04 for the time being. Hope this problem is solved soon as 11.10 is fantastic (other than this problem).

I was away from the affected machine for the weekend. I've gotten it to the point of intolerability. I'll upload the log I made.

beginning: 746556 176164
end: 878552 255664

I think I have found a solution to this. On my Sony Vaio VPCF11S1E running an nVidia 330M, I did this:

1. Start CompizConfig Settings Manager.
2. Type in "workaround" in the filter text box.
3. Tick "Fix screen updates in XGL with fglrx".
4. Tick "Force synchronization between X and GLX".

I have no idea what these do, but it seems to have solved "jerky/laggy window movement" issue for me in 11.10.

I have reproduced the problem with the PPA version of compiz. It was *much* harder to reproduce it with the PPA version, though.

I think it might be related to memory stress - my system ran out of RAM and was using swap heavily, glxspheres dropped to around 40fps, and compiz was only reported as using 31MB of RAM instead of the more normal 120MB. Killing processes so that RAM usage returned to normal didn't help, though. (Currently the system is showing 37MB of swap usage.)

Restarting unity and then compiz didn't help - in fact performance dropped to 30fps, although compiz was again using 120MB. Logging in and out also didn't help (still 30fps).

Restarting lightdm made performance go back up to 40-44fps.

('Force sync between X and GLX' doesn't help, either. But the jerky windows movement must be a different issue because it occurs independently of the glxspheres slowdown - I don't have jerky windows at the moment but I do have the drop in glxspheres' fps.)

And in fact a full system reboot hasn't helped, either. glxspheres is running at 30-40fps.

Well spotted Scott. I hadn't looked at the Workarounds section for a very time and didn't know it had syncing options.

I suggest you will get the best performance using the workaround option "Force full screen redraws (buffer swap) on repaint", but if will perform well ONLY if you have ppa:vanvugt/compiz enabled. Because optimizing buffer swap performance is part of the fix for bug 763005 which is only fixed in my PPA so far.

The above suggestion, in theory, is also equivalent to a fix for bug 880707.

@Chauncellor, your log suggests you *might* have a leak-related slowdown. But the leak is not rapid enough to be sure. Please try the suggestion in comment #40.

Enabling "Force full screen redraws (buffer swap) on repaint" has made a world of difference to me. It works well without my PPA, but works even better (even smoother) with my PPA.

Thanks for the pointer Scott. You made my day.

Enabling "Force full screen redraws (buffer swap) on repaint" makes moving windows better for me, too - it stops unsightly tearing occurring around the window border during the move.

I've now got the 3d-performance degradation bug persistently, ie competely reproducibly between reboots. So it surely must be a setting that compiz is storing persistently. Any ideas?

Rocko, that "unsightly tearing" is bug 880707.

As for your ongoing framerate problems, I suspect a major factor is compiz starting to draw each frame at an inappropriate time, like very close to the start of the monitor's vertical refresh. I think the fix for that in future will be to enhance compiz to use GLX_INTEL_swap_event. In the mean time, you might be able to work around that issue by setting:
  Detect Refresh Rate = OFF
  Refresh Rate = Double your monitor refresh rate.

Sorry in advance if it doesn't work, but it's worth a try.

FYI, on my Sandybridge graphics using "Force full screen redraws (buffer swap) on repaint", I found graphics were most smooth if I also disable "Sync To VBlank". That also disables the fix from my PPA, so you don't really need the PPA unless you have ATI/AMD graphics.

Also, the Intel graphics are more smooth with TripleBuffer enabled (the default). Although glxgears reports a higher frame rate with TripleBuffer disabled, I actually experience a smoother desktop leaving TripleBuffer enabled.

I tried turning detect frame rate off and setting the frame rate manually to 120 (my monitors both report 59.9 or 60 Hz refresh), but it hasn't helped. Sync to VBlank doesn't help the glxspheres framerate either. It really is most odd, because up until yesterday it would quite happily run at 59.x fps, whereas now it struggles to get 29-34 fps. If I detach the external monitor I can get 40-45fps, but it still isn't anywhere near 60.

I also run ironhide and if I run glxspheres through the nvidia card back into compiz running through the intel card, I only get 50-60fps, whereas before I could get 100-120 fps. And in metacity I can get over 200 fps.

I reverted to the oneiric compiz drivers (thanks for the script, btw) and rebooted and now I get 40-45fps in glxspheres. But not yet 59fps.

If I redirect the glxspheres window (I suspect it means unredirect) via Extra WM Actions, it can manage 59fps (it could before when it was only doing 30fps normally).

Oddly, glxspheres reports a 10% higher framerate if I'm running a build (eg wine) in another process.

I may have spoken too soon. The performance issues have returned, even using the Compiz workarounds. It first started occurring when I setup my email account in Thunderbird 7 and started synchronizing. Then I noticed it when I was streaming a HD video from my NAS drive. Now it's the same as it was before - even when idle, window movement is jerky/laggy.

The symptoms occur on my laptop running an nVidia GeForce GT 330M, and my 2009 iMac with an nVidia 9400 . It does not occur on my desktop AMD A8 PC with an nVidia GTX 460.

I have re-installed 11.04 on my iMac, and graphics performance within Compiz is buttery smooth. I will try performing a fresh 11.10 install on my iMac and trying the Compiz 'workaround' fix.

@vanvugt: I suspect that some of the aforementioned 'workaround' plugin options have fixed the issue with my intel i915 laptop card but none of these workarounds have worked on my nvidia card. Still really terrible window dragging. :/

@Chauncellor, it sounds like your nvidia system simply has the wrong frame rate. Please check your nvidia control panel to verify DynamicTwinView is indeed turned off. Please also try Detect Refresh Rate = off, and set the correct Refresh Rate manually in CCSM.

Failing all that, if you continue to have problems with your nvidia system then you're probably not experiencing the same problems as Rocko reported in this bug. So you'll need to search for another bug, or just log a new one for your nvidia problem.

I'm now getting 50-52fps. Still no rhyme nor reason to this!

Is there a way I can get any useful debugging output, eg to see what compiz is treating as the frame rate or where it is waiting for something before drawing to the screen? I've turned off both ccsm flags that say 'Sync to VBlank' but surely it must be applying this somewhere anyway for it to run so slow.

Compiz has a Benchmark plugin in the compiz-plugins-extra package. However in my experience it is grossly inaccurate and does not represent the current frame rate that compiz is actually achieving.

The frame rate that compiz tries to use is determined by the Composite settings: Detect Refresh Rate and Refresh Rate. You should try tweaking them with Detect Refresh Rate off and increasing Refresh Rate.

Sorry I don't know a reliable way to get output from compiz about the rate it is actually achieving. But I don't think you should trust the Benchmark plugin.

In order to avoid this bug becoming a vague never-ending discussion about hearsay desktop performance, I have updated the bug title and description to be more specific and reproducible. Now the bug is confirmed.

If you can't reproduce the bug using the exact test case in the Bug Description then please don't add any more comments to this one and log a new bug instead.

Just a note that the performance of glxspheres reflects how fast the desktop 'feels'. I suspect that all compiz animations are being limited to whatever fps glxspheres can manage.

And would you believe it, glxspheres now is back at 59.x fps.

I was playing around with ccsm and looked at preferences/profiles, which hung unity completely and disabled the unity plugin. There is something strange going on there: according to gconf-editor, I had a profile called 'fooo', and ccsm showed 'Default', and then two profiles with random characters in their name. Even after I deleted the 'fooo' profile setting manually from the .gconf directory and restarted unity, ccsm still shows 'Default' and a second profile with random characters, although there is no second profile.

Setting "Force full screen redraws (buffer swap) on repaint" drops the frame rate from 59 to around 40 fps, whether or not it is waiting for vsync.

That is to be expected. Using pure buffer swaps is (presently) much more CPU intensive for compiz than the default rendering method, because it (presently) has to redraw every part of the screen on every frame (60 times per second). The default rendering method for compiz only tries to redraw what changes, but doesn't use buffer swapping so will cause tearing.

It's a trade-off, and obviously why "Force full screen redraws (buffer swap) on repaint" is not turned on by default. I hope that we can eventually make buffer swapping efficient enough that it can be turned on by default (part of the fix for bug 880707, but apparently also in progress upstream in compiz).

I just realized the cause of this slow-down is Unity (which is a plugin of compiz). If I disable the Unity plugin in CCSM, obviously the launcher and panel disappear, but instantly the frame rate of glxspheres64 and glxgears increases to the same as in Unity-2D or Gnome Shell.

And here is a nice graph from Achim's duplicate...
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/871640/+attachment/2534367/+files/unity_performance.pdf

I've seen the slowdown a few times since I last reported back. Once was after I ran remote X sessions on the target computer from another computer: when I returned to the target computer, it was running much slower than normal. At other times it has happened when there are a fair few applications running, eg Netbeans, some Java windows, Firefox, and Thunderbird.

After seeing that graph, perhaps it is a consistent problem (the difference between unity in Natty and Oneiric is astonishing)... but the issue I originally reported turned out to be a deterioration-in-performance issue that sometimes persists across several reboots.

Rocko, as per comment #53, we need to treat each bug as a separate bug. Could you please log the deterioration issue as a new bug, unless someone else already has?...

Here are my test results, though they are slightly skewed by the improvement in the intel driver between natty and oneiric...

OS WM glxspheres glxgears
------- ----------------- ---------- --------
natty Unity-3D 30 60
oneiric Unity-3D 45 54
        Compiz (no unity) 60 60
        Gnome Shell 3.2 60 56
        Unity-2D 60 60

>> ...we need to treat each bug as a separate bug...

You're hijacking my bug now? :(

BTW, I don't think glxgears is a good 3d benchmark - it was only ever intended as a quick check that GLX was available. I believe glxspheres is a much better benchmark, which is why it's included in virtualgl.

If we're just talking about glxspheres, I get almost 60fps in Unity-3D normally in Oneiric (ie when I'm not experiencing the unexpected slowdown), unless I turn on "Force full screen redraws (buffer swap) on repaint", in which case I get frame rates similar to yours.

I have excellent bad news :)

Bug 880707 (the unsightly tearing) seems to have the same root cause. I think there's a good chance both will be resolved by a single fix.

I know glxgears is a dirty word. That's why the test case uses glxspheres. But the conclusions are the same.

My benchmarks were done without "Force full screen redraws (buffer swap) on repaint".

Sorry if it seems like I hijacked the bug. I'm just trying to get this (and similar) bugs resolved as quickly as possible, with minimum confusion. And that (always) means logging each bug separately.

I believe this bug still matches your original bug description most accurately.

@Rocko,
P.S. Chauncellor was going to log a bug about the gradual degradation problem soon. Keep an eye on his bugs too.

@Rocko and anyone else affected. I've made a bug dealing with slow degradation of desktop performance at bug 888039. Come join the party.

Status update:

I've found both this and bug 880707 are caused by a combination of Unity getting slower in oneiric than natty, and compiz (which is unchanged) being too inefficient to render such slow plugins smoothly. So in a way, the trigger is Unity but the real bug is Compiz itself.

Regarding this bug in particular, I stumbled across a nasty solution, which did indeed fix the frame rate problem. However it only improves the logical frame rate available to 3D apps and actually makes the screen appear to stutter and tear worse than before. The fix *roughly* involved raising the priority of the timer that renders the screen in compiz. However this actually makes appearances worse because it's then rendered at a higher priority than window resize/redraw operations, so the latter deteriorates.

It seems like the best solution to this bug will indeed involve optimizing the Unity plugin. No leads yet on which part of Unity needs fixing.

I think that the framebuffer object implementation in unity might be the cause of the slowness.

Currently, on every frame, we will bind and unbind a framebuffer object to capture the entire screen into, and then paint the entire screen on to the display every time the display is painted (at around the same time the nux stuff is blitted on to the screen). This is (obviously) used to do the blurs, which are painted on top of the scene below the nux widgets like the launcher and friends.

Doing glBindBuffer flushes the pipeline and (might?) block the CPU if I remember correctly. I think that if the nux widgets don't need to be updated, then nux doesn't draw anything or bind any buffers at all, and the just blits its existing buffers into a running context (though, I need to confirm here that WindowThread::renderFromForeignCmd) actually does *only* that.

Daniel, can you do a quick measure of performance with UnityFBO::bind (), UnityFBO::unbind and UnityFBO::paint set to return immediately ? If it increases, then that is definitely the cause. I had a look into whether or not this could be impacting performance a few months ago, but I didn't notice any difference on my machine (nouveau 8600GT), but I wasn't measuring the performance in that case.

I have some proof of concept code I wrote here a few months ago that only binds framebuffer objects if the blurs need updating. I think that if this is the cause of the slowness, then this would definitely be a good solution, since we don't use the framebuffer objects for anything else anyways.

(I'm currently studying for exams, so I don't really have time to look into this right now :( )

Thanks Sam.

Confirmed the bug does go away when I disable UnityFBO::bind (), UnityFBO::unbind and UnityFBO::paint. Of course, that disables all the nice blurring, but now I get full frame rate from all apps (!)

I only had this bug in progress because I thought I had fixed it with other compiz optimizations, but they are hit and miss. Fixing UnityFBO looks like an infinitely better solution. I'll probably get it done this week.

Also, disabling the blur when the dash is not visible would probably solve bug 865006.

On Sun, 13 Nov 2011, Daniel van Vugt wrote:

> Also, disabling the blur when the dash is not visible would probably
> solve bug 865006.
>

Thanks Daniel.

The BackgroundEffectHelper class has a static list of active blur regions,
when that's zero, I'd say just don't bind the framebuffers (but you will
need to do glCopyTexSubImage2D into the framebuffer once you enable the
framebuffers again to avoid artifacts)

> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in Ubuntu.
> https://bugs.launchpad.net/bugs/861061
>
> Title:
> Unity makes 3D apps run much slower.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861061/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

Thanks, I'll take a good look another day.

Only one question: Is it acceptable to disable the panel blur for people
who have non-standard unity plugin settings like me? (panel opacity < 1.0)

Given panel opacity is meant to be 1.0, I don't *think* that would be
breaking the unity design (?)

On 13/11/11 17:45, Sam Spilsbury wrote:
> On Sun, 13 Nov 2011, Daniel van Vugt wrote:
>
>> Also, disabling the blur when the dash is not visible would probably
>> solve bug 865006.
>>
>
> Thanks Daniel.
>
> The BackgroundEffectHelper class has a static list of active blur regions,
> when that's zero, I'd say just don't bind the framebuffers (but you will
> need to do glCopyTexSubImage2D into the framebuffer once you enable the
> framebuffers again to avoid artifacts)
>
>> --
>> You received this bug notification because you are a member of compiz
>> packagers, which is subscribed to compiz in Ubuntu.
>> https://bugs.launchpad.net/bugs/861061
>>
>> Title:
>> Unity makes 3D apps run much slower.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861061/+subscriptions
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~compiz
>> Post to : <email address hidden>
>> Unsubscribe : https://launchpad.net/~compiz
>> More help : https://help.launchpad.net/ListHelp
>>
>

On Sun, 13 Nov 2011, Daniel van Vugt wrote:

> Thanks, I'll take a good look another day.
>
> Only one question: Is it acceptable to disable the panel blur for people
> who have non-standard unity plugin settings like me? (panel opacity < 1.0)
>
> Given panel opacity is meant to be 1.0, I don't *think* that would be
> breaking the unity design (?)
>

I'm not sure, however, blur-behind-panel shouldn't come at much of a
performance cost. Remember that the framebuffer object only needs to be
bound and updated if a relevant blur region needs to be updated, so if
there's no intersection of the damage region in a paint cycle there is no
need to bind the fbo.

However, there is a case where the blur will slightly lag behind whatever
is being painted because the damage calculation will come at the end of
the paint cycle and this will be too late to update the panel blurs until
the next paint. In that case, we'll need to use a core change (change in
the API) which is only available in the precise version of compiz, which
makes CompositeScreen::damageRegion a wrapped function, and in that case,
the framebuffer object would need to be bound, and glCopyTexSubImage2D
would be used to copy the backbuffer into the framebuffer.

I can ask for design feedback on this, though, on first principles I'd say
that blurs should work that either they are on, or they aren't. I know
that last cycle we wanted to do blur-behind-launcher all the time too, and
we hit this same limitation, to which is largely solved by the solution I
described above. However, at the time, compiz was in API freeze.

>
> On 13/11/11 17:45, Sam Spilsbury wrote:
>> On Sun, 13 Nov 2011, Daniel van Vugt wrote:
>>
>>> Also, disabling the blur when the dash is not visible would probably
>>> solve bug 865006.
>>>
>>
>> Thanks Daniel.
>>
>> The BackgroundEffectHelper class has a static list of active blur regions,
>> when that's zero, I'd say just don't bind the framebuffers (but you will
>> need to do glCopyTexSubImage2D into the framebuffer once you enable the
>> framebuffers again to avoid artifacts)
>>
>>> --
>>> You received this bug notification because you are a member of compiz
>>> packagers, which is subscribed to compiz in Ubuntu.
>>> https://bugs.launchpad.net/bugs/861061
>>>
>>> Title:
>>> Unity makes 3D apps run much slower.
>>>
>>> To manage notifications about this bug go to:
>>> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861061/+subscriptions
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~compiz
>>> Post to : <email address hidden>
>>> Unsubscribe : https://launchpad.net/~compiz
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>
>
> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in Ubuntu.
> https://bugs.launchpad.net/bugs/861061
>
> Title:
> Unity makes 3D apps run much slower.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861061/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : co...

On Sun, 13 Nov 2011, Daniel van Vugt wrote:

Another totally unrelated thing, but kind of related while you're looking
into the framebuffer object code.

I did some work about a month ago to fix the "flicker" artefact that
people saw when resuming from expo / on transformed screens because we
were using one framebuffer object per output rather than per-screen. That
can be found in lp:~smspillaz/unity/unity.big_fbo . However, at the moment
I can't merge it because nobody has tested it on fglrx (I will be looking
to aquire an ATI machine at the end of the year probably if nobody does),
and I did some ork in there which intiailly didn't work due to a bug in the nvidia
driver (which I have later worked around), and I want to make sure that I
don't push something that's going to break the display on fglrx.

That work is somewhat related to this, so feel free to check out out too.

Cheers,

Sam

> Thanks, I'll take a good look another day.
>
> Only one question: Is it acceptable to disable the panel blur for people
> who have non-standard unity plugin settings like me? (panel opacity < 1.0)
>
> Given panel opacity is meant to be 1.0, I don't *think* that would be
> breaking the unity design (?)
>
>
> On 13/11/11 17:45, Sam Spilsbury wrote:
>> On Sun, 13 Nov 2011, Daniel van Vugt wrote:
>>
>>> Also, disabling the blur when the dash is not visible would probably
>>> solve bug 865006.
>>>
>>
>> Thanks Daniel.
>>
>> The BackgroundEffectHelper class has a static list of active blur regions,
>> when that's zero, I'd say just don't bind the framebuffers (but you will
>> need to do glCopyTexSubImage2D into the framebuffer once you enable the
>> framebuffers again to avoid artifacts)
>>
>>> --
>>> You received this bug notification because you are a member of compiz
>>> packagers, which is subscribed to compiz in Ubuntu.
>>> https://bugs.launchpad.net/bugs/861061
>>>
>>> Title:
>>> Unity makes 3D apps run much slower.
>>>
>>> To manage notifications about this bug go to:
>>> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861061/+subscriptions
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~compiz
>>> Post to : <email address hidden>
>>> Unsubscribe : https://launchpad.net/~compiz
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>
>
> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in Ubuntu.
> https://bugs.launchpad.net/bugs/861061
>
> Title:
> Unity makes 3D apps run much slower.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/861061/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

I have now tested my proposed fix with intel, nouveau, nvidia and radeon. The fix works well in all cases and the frame rates reported by apps now all match the monitor's refresh rate.

However... just because the app reports a good frame rate does not make the picture nice and smooth as I found with radeon. To get visually smooth graphics you may also require the fix for bug 880707, with it's super new frame timing algorithm ;)

Even better, I have now tested the fix with intel, nouveau, nvidia, radeon and fglrx. It works in all cases, even though I could only reproduce the bug with intel, radeon, nouveau and fglrx.

Hey, that's super! Any chance of a PPA to try out?

Except that I would also need the http://sarvatt.com/downloads/patches/byegeis.patch patch to turn off geis, since I installed xorg-edgers, which comes with xserver 1.11, under which unity crashes at startup due to the missing multi-touch support, and I can't uninstall xorg-edgers now due to a bug in ppa-purge to do with multi-arch. :(

In case this information helps any, I am now getting only 1-2 frames per second in glxspheres (which is using a whole CPU core). The rest of the desktop is quite responsive, though.

I'm using compiz 1:0.9.6+bzr20110929-0ubuntu6, unity 4.24.0-0ubuntu2b1+nogeis and the xserver-xorg-video-intel 2:2.17.0+git20111125.16f5e224-0ubuntu0sarvatt~oneiric from xorg-edgers.

If I run glxspheres through the nvidia card via virtualgl, I get around 60fps (compared to 100-120 fps normally).

I can't think of a reason why glxspheres would be running at 1-2 FPS.

I will be adding this fix to my PPA, when the dust has settled, and ideally after its been reviewed. Too many times I've rushed fixes into a PPA and then needed to change them, in multiple locations :P

The good news is that the fix for this bug is sufficiently tiny that I think we can look at proposing it as an oneiric-update (after it's been accepted upstream).

Hi,

Sorry my English

For if it helps someone:

I had opened the bug Bug # 892544, but I think my problem is exactamene the same as this bug.

This bug Occurs on a clean install of 11.10 [64 bits] with ATI Radeon 5770 graphics card (Evergreen) and radeon driver

My system works correctly the first time you start, but after resume suspend everything becomes slow.

How to play:

Go to Unity Dash, show all applications, move icons up and down with the scroll bar, suspend and resume, perform the same operation and notice that is very slow.

First boot, out the --> vblank_mode=0 glxgears:

16186 frames in 5.0 seconds = 3237.179 FPS
17110 frames in 5.0 seconds = 3421.557 FPS
19193 frames in 5.0 seconds = 3838.410 FPS
16229 frames in 5.0 seconds = 3245.769 FPS

After the suspend/resume, out the --> vblank_mode=0 glxgears:

417 frames in 5.0 seconds = 83.148 FPS
299 frames in 5.0 seconds = 59.721 FPS
299 frames in 5.0 seconds = 59.721 FPS
299 frames in 5.0 seconds = 59.719 FPS

Mario, your bug is not related to this one. Your bug looks like an issue in the radeon driver forcing compulsory sync to vblank after resume from suspend.

Hi Daniel,

I've tried to update with ppa xorg-edgers and the problem continues, I made a lot of tests but no results.

With 11.04 this bug did not occur, and the logs do not see anything relevant.

I wanted to try R600c in 11.10, you know any way to substitute Gallium R600g for Classic Mesa R600c in 11.10?

I do not know if it's a bug in radeon driver, but "unity --reset" solves the problem until the next suspend / resume.

Thanks for your help

Mario, please post your comments related to bug 892544 in bug 892544. Thanks...

Clarified the bug title because this bug actually affects all apps, not just 3D. It's just that most people don't or can't measure the frame rate of 2D apps. :)

Experimental fixes for this and related performance bugs are now available
for testing in ppa:vanvugt/compiz and ppa:vanvugt/unity. For the best
results I recommend trying both together. But testing them individually is
useful too.

IMPORTANT NOTES:

  * The fixes in ppa:vanvugt/compiz REQUIRE that "Sync To VBlank" is ENABLED
    in CompizConfig Settings Manager (OpenGL section).
    This is the default setting when Ubuntu 11.10 is installed.

  * When using ppa:vanvugt/compiz you should DISABLE the workaround
    "Force full screen redraws (buffer swap) on repaint" in
    CompizConfig Settings Manager (Workarounds section).
    This is the default setting when Ubuntu 11.10 is installed.

  * I don't claim to have fixed all tearing. I only claim that the amount of
    tearing in oneiric with the fix is no longer worse than in natty.

  * nouveau: If you are using the "nouveau" driver for NVIDIA chips you will
    need to enable sync-to-vblank support in the driver options because
    nouveau has it disabled by default. You can do this by editing
    /etc/X11/xorg.conf and adding:
       Section "Device"
           Identifier "My Graphics"
           Option "GLXVBlank" "on"
       EndSection
    Then log out and in again for it to take effect.

  * fglrx (Catalyst): The fglrx driver also disables sync-to-vBlank support
    by default. To fix this:
      1. Open Catalyst Control Center.
      2. Go to 3D > More Settings.
      3. Set "Wait for vertical refresh" to
         "On, unless application specifies".

  * Please don't try using the Benchmark plugin in compiz-plugins-extra
    because it is broken and misleading (bug 898548).

Please leave feedback in the relevant bug reports.

- Daniel

---

ppa:vanvugt/compiz | https://launchpad.net/~vanvugt/+archive/compiz
compiz (1:0.9.6+bzr20110929-0ubuntu6vv2) oneiric

  * Added proposed fix for inaccurate frame timing causing tearing and
    stuttering.
    (LP: #880707) (LP: #888039) (LP: #92599) (LP: #798868) (LP: #876575)

ppa:vanvugt/unity | https://launchpad.net/~vanvugt/+archive/unity
unity (4.24.0-0ubuntu2b1vv4) oneiric; urgency=low

  * Fix major performance regressions due to unnecessary UnityFBO binding
    (LP: #861061) (LP: #880707)
    UnityFBO was being bound even when not required. This caused major lag in
    glPaintOutput, which slowed down all rendering. This was seen in reduced
    framerates in apps (LP: #861061) and significantly worse screen tearing
    with Unity 4.x compared to 3.x (LP: #880707).

Great, trying them now on my Sandy Bridge setup.

My first observations are that right after logging in I now get 130-150 fps instead of 100-120 fps from the nvidia card running through virtualgl, and that I'm not seeing tearing any more when I move windows around. Thanks!

I have installed both ppa's and I can confirm that FPS seem too be back like it was in natty.
I have tested xbmc, ioquake3, RevengeOfTheTitans and they all seem to run much better now.

00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

Thanks! Just installed them both on my laptop with an Nvidia NVS 140M and a C2D T9300. First impressions:

- I can also confirm the increase of the number of fps in glxspheres to ~140 just after logging in. This is identical to the results in gnome-shell.
- No tearing when moving windows around

Downsides:
- Aggregate CPU usage of compiz, unity and X is constantly above 5% (3% compiz, 1% unity and more than 1% X). Gnome-shell typically uses just 1-2%.
- After several minutes of using chrome, thunderbird and other applications, glxspheres frame rate dropped to 40-70fps.

Other thoughts:
- enabling of chrome flags "GPU compositing on all pages" and "GPU Accelerated Canvas 2D" has quite a detrimental effect on frame-rates.

All, the issue with windows freezing while being dragged is being handled in bug 773861. At least, that's where I'm directing all reports of the problem.

Interestingly, the fix for bug 897045 provides an extra improvement in frame rates when testing glxspheres. I'll try to get that in ppa:vanvugt/compiz within the next day.

I can confirm the improvement in framerates with glxspheres - the latest version from the PPA now gives a consistent 150-160 fps for the nvidia card via virtualgl. It's significantly better than mutter now.

I see I'm joining in here quite late, but the problem I'm experiencing fits this bug description perfectly. I'm using the ATI Radeon open source driver because my video card is no longer supported by the flgrx driver. (I don't know if this is relevant but after booting up the machine I always suspend and resume before logging in otherwise my fans never come on and the laptop gets too hot).

I've just installed all the packages from your PPAs (both Unity and Compiz) and I find that whilst the performance is slightly better than it was before, it's still not as good as it was in Natty (or in the Oneiric default version of Compiz with Unity plugin disabled). I'm using a ATI Radeon X1250 with the radeon open source driver - the proprietary driver doesn't support my graphics card any more.

So unless I've made some mistakes during the installation, which is very possible, it seems that these packages don't fix everything for me.

I haven't done any proper benchmarks but I can see two main differences:
-1 The animations seem to play properly now - by that I mean that although everything seems to happen in slow motion, they are not 'jerky' as they were before
-2 The system feels a bit more responsive, especially to keyboard input when typing. There is still a noticeable lag between pressing a key and the character appearing on screen but nowhere near as much as before I installed the patch
-3 Previously, I could get perfect performance (as I had in Natty) with Compiz with the Unity plugin disabled. Now disabling the Unity plugin doesn't help at all and the problems with the performance remain.

Hope this is helpful

@EliCoten: Regarding when you are using the unity plugin, how recently did you install from the PPA? As of a few days ago there is a new distribution release of unity which gets installed in preference to the PPA's version. If you do "dkg -l |grep unity-common" you should see version 4.24.0-0ubuntu2b1vv5 if you've got the PPA version. Otherwise you've got the slower distribution release.

I got 4.24.0-0ubuntu2b1vv5 and something has changed. First I get no stuttering while dragging windows anymore. Second - Unity dash started to reveal itself after 1-1.5 sec delay. Third - alt-tab switcher (no switcher shows, not even the old 2d one), Win+W and other Unity features don't work for me anymore and I don't know at what stage it happened as I was using Unity 2D for weeks now.

Nothing has changed in ppa:vanvugt/unity for 10 days. And even before that there were very few changes:
http://bazaar.launchpad.net/~vanvugt/+junk/ppa-vanvugt-unity-oneiric/view/head:/debian/changelog

Bucic: I don't think the fix for this bug is related to your new problems.

EliCoten: Please try removing ppa:vanvugt/compiz. It does not contain any code relevant to this bug and is likely causing some regression you talk about. I know I recommended ppa:vanvugt/compiz because it seems to help so many people, but it's still under development. Please try testing ppa:vanvugt/unity alone.

I am totally confident this bug is fixed in ppa:vanvugt/unity. I am not totally confident that ppa:vanvugt/compiz is right for all hardware configurations just yet.

@Daniel: I don't think it is possible to install the version of unity from your PPA any more. The latest version is now 4.24.0-0ubuntu2.1, which supersedes 4.24.0-0ubuntu2b1vv5.

It's only a problem if you're using the proposed (pre-release) packages. ppa:vanvugt/unity is still ahead of the official oneiric-updates. See: https://launchpad.net/ubuntu/oneiric/+source/unity

But I'll try to sync the PPA with proposed some time soon.

The issue with ppa:vanvugt/compiz causing animations to play in "slow-motion" should now be fixed if you update to ppa:vanvugt/compiz version 1:0.9.6+bzr20110929-0ubuntu6vv8.

Sorry I didn't realise I wasn't subscribed to this bug - sorry it's taken me so long to reply.

I uninstalled the Compiz PPA and now I'm using version unity version 4.24.0-0ubuntu2.1vv1 and Compiz 1:0.9.6+bzr20110929-0ubuntu6. It seems to better - at least it's usable - but I still think it's not as smooth as it was when I was running Natty.

After a little more testing, I have found that disabling the Unity plugin from Compiz-Config Settings Manager still increases performance.

I don't have any scientific test or benchmark but I was running a video totem and noticed the following observations:

**Unity Plugin Enabled**
-Video seems to play ok windowed but when I drag it around the screen it doesn't move smoothly (I have wobbly windows enabled and this really shows up the lag)
-Full screen video is not smooth

**Unity Plugin Disabled***
-Video plays fine and there is hardly any noticeable lag when wobbling/dragging the video round the screen
-Full screen video seems to be smooth

So the difference is certainly noticeable, at least under some conditions. For everyday use, the difference is less noticeable but Videos and Wobbly Windows are more noticeable when there's a lag.

So for me, this patch is a great improvement but I don't think it's totally resolved yet.

Tagged power-management. Because the root cause of this bug is Unity constantly (ab)using the GPU even when it should be idle.

@Daniel: re power management, is this what your patch addresses, or it a separate issue?

Yes, my fix or any fix for this bug should reduce GPU power consumption. It may be very significant with some drivers/hardware, but is hard to prove without careful testing. Especially since GPU power hogs don't usually show up in CPU lists like "top".

The fix has finally been committed to lp:unity r1816. Though smspillaz redesigned it slightly to fit in with his other changes. I assume the fix still works...

That's excellent! Thanks for all the great work getting this fixed, Daniel!

I can't wait for r1816 to hit the official repos, especially as I've also experienced the crashes mentioned in the other bugs that r1816 says it fixes.

Daniel, I'm using your ppas, both compiz and unity. I installed them when screenlets were already installed and active on my desktop and everything worked smoothly.
As I tried to remove screenlets, after reboot compiz didn't load anymore. The possible solutions were either re-installing screenlets package and continue using your ppas or downgrade to official versions of compiz and unity (proposed repository).
I don't know if this is a bug, it could be just my system a little messed up, but since the fix is going to official repositories maybe it's worth investigating.

For those who are brave enough and can't wait, r1816 will be hitting the staging ppa in the next 24hours.

Download from https://launchpad.net/~unity-team/+archive/staging/+packages

I can't recommend upgrading just yet: the upgrade from ppa:unity-team/staging removes unity completely at the moment. ("unity : Depends: libnux-abiversion-20111213 but it is not installable", even though the libnux-2.0-0 2.0.0~+bzr534ubuntu0+307 package was built only 5 hours ago.)

I've deciphered some of the branching chaos and found the (unity) fix has slipped into lp:unity/4.0 already (r1726). Now I have created the missing branch links, it's more obvious.

Sam, please be careful. You obviously lost track of which bug fixes your merge proposals contained. But it's excellent to see the fixes for bug 861061 and bug 880707 actually being released.

This bug is now fix-released in unity 4.28.0 "SRU2". Could someone please fix the "unity" Milestone column to show this?

Status changed to 'Confirmed' because the bug affects multiple users.

I now see the correct status should be like that of bug 887465.

Could someone please mark this bug as Fix Committed in unity 5.0.0, and Fix Released in 4.28.0 "SRU2"?

Where is version 4.28, btw? The latest one I can see in oneiric-updates/proposed is still 4.24.

Unity 4.28.0 has been released upstream (for developers only). It's not in any ubuntu branches yet.

Upstream: https://launchpad.net/unity/4.0/4.28.0
Ubuntu: https://launchpad.net/ubuntu/+source/unity

This bug was fixed in the package unity - 5.0.0-0ubuntu1

---------------
unity (5.0.0-0ubuntu1) precise; urgency=low

  [ Didier Roche ]
  * New upstream release.
    - compiz crashed with SIGSEGV in __dynamic_cast() (LP: #853038)
    - unity-panel-service crashed with SIGSEGV in panel_service_show_entry()
      (LP: #861144)
    - unity-panel-service crashed with SIGSEGV in
      panel_indicator_entry_accessible_get_n_children() (LP: #869816)
    - Launcher - Launcher icon for Dash does not highlight when the Alt+F1 key
      shortcut is pressed (LP: #849561)
    - compiz crashed with SIGSEGV in unity::PanelTray::FilterTrayCallback()
      (LP: #868868)
    - [regression] Compiz: Visible tearing is worse in 11.10 than 11.04, even
      when "Sync To VBlank" is enabled, but only when Unity is active.
      (LP: #880707)
    - [regression] All apps have a lower frame rate under Unity. (LP: #861061)
    - compiz crashed with SIGSEGV in
      nux::Property<nux::color::Color>::operator=() from
      unity::switcher::SwitcherController::OnBackgroundUpdate() (LP: #887465)
    - DashSearchBarSpinner.cpp:56: Conditional jump or move depends on
      uninitialised value(s) (LP: #901610)
    - quicklist shows in incorrect position when launched from workspace
      switcher (LP: #914251)
    - Build "show me the desktop" mini-app that adds a show desktop button to
      Launcher (LP: #681348)
    - Select quicklist items with just one right click (LP: #688830)
    - cannot change volume by scrolling on the icon when the SoundMenu is
      opened (LP: #722082)
    - [a11y] Unity launcher buttons are not Actionable (LP: #772573)
    - Ubuntu Start launcher item doesn't start dash with keyboard navigation
      (LP: #825037)
    - multimonitor , window management - Multi-Monitor Maximized Difficulty
      (LP: #843958)
    - [regression] Drag and drop inside dash is very slow with Active Blur
      activated (LP: #851172)
    - Activating an alt-tab icon that holds initially unminimized windows
      should unminimize all windows (LP: #854595)
    - Dash - The Dash category headers are positioned incorrectly
      (LP: #839467)
    - Missing global menu with a semi-maximized window dragged to the right.
      (LP: #861279)
    - Launcher - Dragging and dropping a running application in to the Trash
      should quit the application and (if the app is pinned to the Launcher)
      un-pin the application from the Launcher (LP: #870143)
    - top bar, integrated menu - when a application is first launched, the
      integrated menu should be displayed for 2 seconds before fading out of
      view (LP: #874254)
    - Window control buttons are not shown when an indicator is opened and the
      pointer is over the top-left corner (LP: #890970)
    - Quicklist item using some special chars doesn't show at all
      (LP: #899677)
    - PanelView.cpp:370: Conditional jump or move depends on uninitialised
      value(s) (LP: #901602)
    - unityshell.cpp:1982,1984: Conditional jump or move depends on
      uninitialised value(s) (LP: #901603)
    - Dash Search spinner sometimes doesn't spin at all (LP: #903090)
    - Point of tooltip is misaligned to focused ap...

So far 4.28.0 is working nicely on my system, although after switching external monitors a couple of times, I did notice a massive slowdown in the framerate obtained using optirun glxspheres (ie using the nvidia card via VirtualGL). It slowed down from 150fps after booting to only 60-70fps. (Note that just using glxspheres by itself gave ~59.1 fps instead of ~59.6 fps, so there wasn't a big difference there).

Restarting unity didn't help, but a reboot did. Might this have been an issue in compiz rather than unity?

I'm sure there are other performance bugs we haven't pinpointed yet. If you have Sync To VBlank enabled (which is default) then 60 FPS is probably to be expected. Because the framerate should be the same as your monitor; never higher.

Unfortunately with a few compiz/unity performance bugs pending and their fixes not available for testing yet, it's hard to tell what's what. And very difficult for anyone to identify which bug they're experiencing with certainty. It will get easier as more fixes are released...

Yes, that's true if I run glxspheres through the intel card, but running through optirun, the nvidia card doesn't respect the sync-to-vblank setting, so the expected result is a rate considerably higher than the 60 fps monitor. I get 150fps normally with the fixed unity/compiz, but it regressed down to around 70fps in this case.

Fix Released in oneiric: unity (4.28.0-0ubuntu1) oneiric-proposed; urgency=low

fwiw I just upgraded to Precise, and glxspheres (just running through the intel card) now only gives me 1-2 frames per second. Is this a known issue? Sync-to-vblank makes no difference. I'm running compiz 1:0.9.7.0~bzr2995-0ubuntu5 and unity-common 5.4.0-0ubuntu2.

Sounds bad. Please log a new bug Rocko.

Should I log the new bug against unity or compiz?

If you can reproduce the slowness while you have the Unity plugin disabled in ccsm (unity not running) then log it against "compiz-core". If the slowness goes away while unity is disabled, then log it against unity.

If in doubt, log it against both.

OK, if I disable unity-plugin via ccsm it still runs slow so it looks like I should log it against compiz. The unity animations are still fast, btw.

I reported a new Bug #987304 because suddenly my 3D-Apps are running slow again with ubuntu 12.04 and unity.
Please let me know if you need more information.

Me too - slow fps with 12.04 and unity (even with Unity-5.14 from SRU-1), using Nouveau on NV44:

- Slow fps with compiz running with unity plugin
- Fast fps with compiz running without unity plugin (can be switched in ccsm when selecting the profile called "default")

Examples:
1) briquolo:
- Reference: The briquolo menu screen shows 90fps with Unity-6.2 packages from Quantal compiled on Precise.
- With Unity 0.14 packages, after fresh unity start it gives 50fps and after working a while on the desktop, it drops to around 20 fps.

2) Frozen Bubble (ancient 2D game, does not use OpenGL and isn't heavvy on the animation at all....):
- After working a while on the desktop, the balls in frozen bubble were so slow that they were falling in like with a Cinemal effect which is described as "slow motion" (lets say half or one third of the normal animation speed)

Bernhard,

This issue is now being tracked in bug 988079.