compiz team mailing list archive

[Daniel van Vugt <daniel.van.vugt@xxxxxxxxxxxxx>]

This is a little bit mind-bending, but I've found the problem, at least
on my precise desktop using Intel Sandy Bridge graphics...

1. I disable all the fancy new opengl rendering options so compiz should use regional redraws, so useFbo is always false.
2. On startup, I get a couple of frames with (mask & COMPOSITE_SCREEN_DAMAGE_ALL_MASK) so doubleBuffer.render is called with fullscreen==true. This calls: GLXDoubleBuffer::swap() --> copyFrontToBack() because useFbo was false --> glCopyPixels().
3. After startup, all frames use GLXDoubleBuffer::blit() --> GL::copySubBuffer(), which is now slow.

To make rendering fast again, all I have to do is break the sequence in #2. Either:
  (a) Force fullscreen=false; or
  (b) Comment out copyFrontToBack(); or
  (c) Comment out glCopyPixels()

So the problem, on my desktop where I've done all my performance
comparisons, is that calling glCopyPixels just once or twice on startup
will forever make GL::copySubBuffer take a slow rendering path
thereafter. If I ensure glCopyPixels is never touched on startup then
Mesa stays in fast mode for GL::copySubBuffer.

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

Title:
  [regression][GLES] Benchmark results are 15-40% lower with the gles2
  code (compiz 0.9.8.0)

To manage notifications about this bug go to:
https://bugs.launchpad.net/compiz/+bug/1037411/+subscriptions