Taking of screenshot (gl_readpixels) degrades performance for large figures

[GoogleCodeExporter]

On a full-screen figure a call to gl_readpixels takes a lot of time, even on 
modern hardwar. We even got a MemoryError on a very new PC.

Such a call is currently made in two places. 1) in the taking of a screenshot 
of the shapes of objects (so visvis knows which object is where and can handle 
events apropriately); 2) each axes makes a screenshot and
reuses that if it does not need any updating of its contents.

The latter will probably be fixed when we come around issue 41. The first might 
be more difficult to overcome, but maybe things can improved, for instance by 
reading just a single pixel when needed instead of reading the entire screen on 
every draw.

On the short term, while these issues are still there, we need a way of 
disabling taking the screenshot at the cost of user interaction being disabled 
and axes not being able to re-use their content, respectively. The second case 
can already be disabled by doing Axes.useBuffer = False.

Original issue reported on code.google.com by almar.klein@gmail.com on 15 Aug 2012 at 2:08

[GoogleCodeExporter]

Added property on figure: enableUserInteraction. When set to False the taking 
of screenshots is disabled, which improves performance. 

See revision ff586759f97f

Original comment by almar.klein@gmail.com on 16 Aug 2012 at 11:05

[GoogleCodeExporter]

Original comment by almar.klein@gmail.com on 16 Aug 2012 at 2:39

• Added labels: Milestone-Release1.8

[GoogleCodeExporter]

For screenshots, you might want to render to a framebuffer object and then save 
it. Have a look at glumpy code:

http://code.google.com/p/glumpy/source/browse/glumpy/figure.py#271

Original comment by Nicolas.Rougier@gmail.com on 17 Aug 2012 at 9:00

[GoogleCodeExporter]

Thanks! That would be a great approach. We wanted to use FBO's for rendering 
anyway, so this would fit in nicely.

Why is this approach faster than glReadPixels?

Original comment by almar.klein@gmail.com on 17 Aug 2012 at 9:51

[GoogleCodeExporter]

I'm note quite sure why it is slower but it might be a problem of 
IO/synchronization between CPU/GPU from what I've found. 

Original comment by Nicolas.Rougier@gmail.com on 17 Aug 2012 at 10:53

[almarklein]

I dont care enough to fix it. Would be open to PR's, but closing for now.