compiz team mailing list archive

[Sam Spilsbury <smspillaz@xxxxxxxxx>]

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 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