Hi!

This bug could be caused by vtk: please reassign, if appropriate.

Steps to reproduce:

  $ mayavi2 -d /usr/share/doc/mayavi2/examples/mayavi/data/heart.vtk

The main window shows up.

  * select Add module or filter in the Mayavi pane
  * from the Mayavi object editor, choose IsoSurface
  * rotate and zoom the visualization, until it looks "pretty" enough
  * from the File menu, select Save Scene As > Vector PS/EPS/PDF/TeX
  * in the dialog window, enter "foo.pdf" as Name
  * click on the Save button
  * in the next dialog window, accept default GL2PSExporter properties
    (OK button)

Then try to display the resulting file:

  $ xpdf foo.pdf
  $ gv foo.pdf

After an fairly long wait, the PDF file is shown, but with large
parts of the iso-surface painted black, rather than green.

I've also tried to use non-default GL2PSExporter properties:

  a) disabling "Draw background" leads to the same issues
  b) disabling "Ps3 shading" doesn't seem to help
  c) choosing "simple" Sort doesn't help either
  d) disabling "Occlusion cull" seems to slow down even more xpdf, but
     not gv (without fixing the black areas issue)
  e) disabling "Best root" does not help

Please note that saving the scene as a PNG image works as intended
(but obviously generates a raster image, not a vector one!).

Gaël

reassign 568684 vtk
retitle 568684 "gl2ps-generated PDF images are slow and incorrect"
thanks

Hi VTK Maintainers,

Not sure if this is a vtk or gl2ps bug; please reassign to gl2ps if
appropriate.

Thanks,
Varun

tag 568684 moreinfo
thanks

Here is what I am seeing. What do you call 'slow and incorrect' ?

thanks

On Tue, 6 Sep 2011 14:44:29 +0200 Mathieu Malaterre wrote:

[...]

That's really awkward.
I've just re-performed the test and I am *still* able to reproduce the
bug.

I am attaching what I obtain.

Now I suppose we should try to figure out where our systems differ...

I am currently using libvtk5.6/5.6.1-6+b1 and libgl2ps0/1.3.6-1 .

Could it be a video-driver-specific issue?
I am using xserver-xorg-video-intel/2:2.14.0-4 (pinned to that version,
because of the unfortunately still unfixed bug #624720) on an "Intel
Corporation 82G965 Integrated Graphics Controller".

Does this additional information help?

Please CC, BTS won't do that by itself.

I do not believe the bug is in neither libgl2ps, nor vtk. I would
simply try to use the mesa implementation of opengl instead of intel.
Can you change your glx implementation, I believe one can do:

$ sudo update-alternatives --list glx

Or alternatively use LD_PRELOAD to force loading of libGL.so.1.2 from
mesa instead of intel (check with glxinfo which one is loaded)

HTH

Sorry, I thought you were a member of the vtk packaging team and were
triaging bugs. Hence, I thought you were subscribed to the vtk package
(at least to its bugs) via the PTS:
http://packages.qa.debian.org/v/vtk.html
software OpenGL implementation (Mesa), instead of direct rendering.
Is that correct?

Please give detailed instructions: back in the old times, I used to be
used to struggle to *enable* direct rendering. Nowadays, Intel
integrated graphics works out of the box with Debian.
I have never struggled to *disable* direct rendering...   ;-)

# update-alternatives --list glx
update-alternatives: error: no alternatives for glx.

Could you please explain more in detail?

It *could* help to pinpoint the problem, but I am not sure how to
proceed to perform the tests you suggest...

I managed to reproduce the bug even on sid, with

  xserver-xorg-video-intel/2:2.16.0-1
  libvtk5.6/5.6.1-6.1
  libgl2ps0/1.3.6-1

reassign 568684  xserver-xorg-video-intel/2:2.16.0-1
thanks

As said before, I believe this is due to a bug in intel driver.

HTH

yes !

I am not sure how it works for you. On my nvidia machine I do have it here:

/usr/lib/mesa-diverted/libGL.so.1

You may also use apt-get source mesa + dpkg-buildpackage to recompile
it yourself (there might be other easier solution).

ok

$ export LD_PRELOAD=/usr/lib/mesa-diverted/libGL.so.1
$ glxinfo

I am not sure either. This is why I reassigned it to proper package,
you may find opengl guru there.

HTH

[...]

I have no diverted mesa:

  $ ls -altrF /usr/lib/mesa-diverted
  ls: cannot access /usr/lib/mesa-diverted: No such file or directory

I hope it's not that complicated...

[...]

Hello X Strike Force!
Can you reproduce this bug on a box with Intel integrated graphics?
Could you please help?

Thanks a lot for your time!

tags 568684 - moreinfo
thanks


On Tue, 27 Sep 2011 19:41:11 +0200 Francesco Poli wrote:

[...]
Without some help, I am not able to perform other tests.
I am therefore dropping the moreinfo tag: if you need more information,
then feel free to ask and re-add the moreinfo tag...

What's "this bug"?  I don't have time to go re-read every bug log to
find out what it's about, sorry.

Cheers,
Julien

At the very least, provide output of glxinfo, dmesg, X log, and a clear
description of the problem.

Also from the bug log this sounded like a GL issue, in which case
xserver-xorg-video-intel is not involved.

Cheers,
Julien

On Wed, 12 Oct 2011 23:05:46 +0200 Julien Cristau wrote:

[...]
http://bugs.debian.org/568684#5
The only thing that has changed in the meanwhile is that, after
installing mayavi2, you have to uncompress the data file:

  $ zcat /usr/share/doc/mayavi2/examples/mayavi/data/heart.vtk.gz > /tmp/heart.vtk
  $ mayavi2 -d /tmp/heart.vtk

The PDF file I obtain is slow to visualize and, above all, has parts of
the surface incorrectly painted black (rather than green).

Mathieu Malaterre performed the test on his system and obtained a
correct PDF file (with no black parts): see
http://bugs.debian.org/568684#28

Since I still see the issue:
http://bugs.debian.org/568684#35
and we found out that we use different video hardware, we thought that
the issue could be in the xserver-xorg-video-intel package.

I am attaching the output of glxinfo, dmesg, and the X log, in gzipped
form to save network and BTS resources...

Please help me in finding the right package this bug report should be
reassigned to...