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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to 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 -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
