Hidden areas of axes not drawn properly with compositing window manager

[GoogleCodeExporter]

Parts of axes that are not visible (e.g. those scrolled out of a viewport) are 
not drawn properly when they become visible.  Instead, they appear black or 
have information from another part of the axes.  This only affects axes; 
legends and padding around the axes are properly rendered.  I've seen this 
problem with both the GTK and WX backends, so I believe it is 
backend-independent.  I get this problem with Compiz (a compositing window 
manager) but not with Metacity (non-compositing).

The problem seems to be with the axes redrawing themselves from screenshots.  
If I disable this feature, this problem does not occur.  My guess is the 
screenshot fails to get the hidden regions of the axes, and instead gets zeros 
or garbage.

Original issue reported on code.google.com by rschr...@gmail.com on 25 Jul 2011 at 3:13

[GoogleCodeExporter]

> My guess is the screenshot fails to get the hidden regions of the axes, and 
instead gets zeros or garbage.

That would be my guess as well. Is there any way to detect this, or to detect 
that Compiz is being used, so that the buffering can be turned off 
automatically? 
(I have no idea myself.)

If not, we could at least document this behavior in the useBuffer property.

I reckon that this is related to embedding visvis figures in Reinteract, 
because having a visvis figure scrolled out of viewport is quite uncommon in 
normal use? 

Original comment by almar.klein@gmail.com on 25 Jul 2011 at 8:57

[GoogleCodeExporter]

I think checking for Compiz specifically is a bad idea, as we would also 
have to test and possibly check for KWin, Mutter, and any other window 
manager to come down the pike.  Some quick Googling suggests it's 
possible to detect compositing by looking at X properties, but I haven't 
seen a Python example yet.

It would be better if _Screenshot would be able to tell whether it got 
the whole axes or not.  I've been poking around, but I haven't found 
anything better than, "Do the axes have a lot of black?"  (I was hoping 
the alpha channel might give us a clue, but it doesn't seem to work that 
way.)

We could try to sidestep this whole issue by rendering to a framebuffer, 
and then copying that over to the screen.  (Since this should be done 
entirely on the GPU, it might also perform better than the current 
system.)  But framebuffers are an extension to OpenGL, and I don't know 
what that means in terms of support.  It might be worth it to implement 
a framebuffer solution and fall back to the screenshot method if 
framebuffers aren't supported.  (And hope that if a card doesn't support 
framebuffers, it won't be running a compositing WM.)  But this would 
give us two rather different code paths here, and I can see them getting 
out of sync.

Yep.  It's not a worry at all when using visvis from the interpreter. 
But it could come up anytime a figure is embedded in an application.

Original comment by rschr...@gmail.com on 26 Jul 2011 at 4:59

[GoogleCodeExporter]

We could render to a framebuffer and fall back to not-buffering the axes 
contents if framebuffers are not supported; the buffering is not crucial, it 
only makes thing run smoother when you have multiple axes in one figure. I'm 
just wondering how much change is required to implement this. 

Therefore I agree that detecting whether _Sreenshot got the whole image would 
be much nicer. One idea that comes to mind is drawing a single pixel in each 
corner in a specific color and then checking whether the pixels do indeed have 
this color. Of course, we then have ugly corner pixels, but maybe we can make 
them transparent so in effect the axes has smooth corners :)

Original comment by almar.klein@gmail.com on 26 Jul 2011 at 11:17

[GoogleCodeExporter]

FWIW, this doesn't seem to be a problem with current versions of Compiz or 
Mutter.  So it's not an issue with all compositing window managers, but some 
implementations.

I still think the framebuffer would be a cleaner way to go, but I can't say I'm 
all that excited about breaking and then fixing things that are already 
working.  I've lowered the priority to reflect that it's not a universal 
problem.

Original comment by rschr...@gmail.com on 2 Jun 2012 at 2:31

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Related to issue 41, setting milestone accordingly.

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

• Added labels: Milestone-Release1.8