Closed GoogleCodeExporter closed 1 year ago
> 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
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
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
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
Related to issue 41, setting milestone accordingly.
Original comment by almar.klein@gmail.com
on 16 Aug 2012 at 2:40
Not sure if this is still an issue. I've used Visvis many times on Linux without problems.
Closing.
Original issue reported on code.google.com by
rschr...@gmail.com
on 25 Jul 2011 at 3:13