[Paraview] offscreen display trouble revisited

[David Cole]

I don't know if this will help at all... but, here goes:

In your original email you said you have VTK_USE_OFFSCREEN on but
VTK_USE_DISPLAY off.

VTK_USE_OFFSCREEN is simply used to control the *default* value of
vtkRenderWindow's OffScreenRendering property. VTK_USE_DISPLAY controls what
VTK tests are run: tests that require the display (whether offscreen
rendered or not) are skipped if VTK_USE_DISPLAY is off.

So, it probably makes no difference to your particular case, here, but in my
mind, it doesn't make a lot of sense to set VTK_USE_OFFSCREEN to ON unlesss
VTK_USE_DISPLAY is also ON. "OffScreen" rendering occurs invisibly, but it
still requires use of the display...

Now this is all strictly from the VTK side of the fence. Don't know if these
settings propagate to any other logical implications on the ParaView side of
the fence.


HTH,
David


On 11/17/06, John Biddiscombe <biddisco at cscs.ch> wrote:
>
> Francois
>
> vtk is compiled with OSMesa, I was using a cvs version around the end
> octobers - I just did a cvs update and clean build and the same problem
> exists. However, I believe I had problems /before /26 oct. I originally
> attributed my trouble to using pvserver from pv3 and pvclient from pv2,
> but I'm not doing that any more - it was working in early oct, but I
> don't know exactly when I broke it.
>
> I tried various DISPLAY localhost:0.0 and :0 combinations, with and
> without xservers available, but always the same trouble.
>
> (The machines are headless, so offscreen rendering must be software)
>
> Anything else I can try?
>
> JB
> > Hi,
> >
> > Assuming you use cvs version of ParaView, there was some change related
> to offscreen rendering in VTK on October 26. Is it when the warnings started
> to occur?
> >
> > Under X11, if vtk was compiled with OSMESA (OS=OffScreen) it creates an
> OSMesa window and an OSMesa context.
> > Otherwise, (NEW) it tries to use a hardware accelerated offscreen
> rendering by creating a window and an OpenGL context and asking for OpenGL
> extensions GL_EXT_framebuffer_object and GL_ARB_texture_non_power_of_two.
> > It those extensions are not available, the OpenGL context and window are
> destroyed and it tries to use a Pbuffer offscreen. If not available, it uses
> a GLX Pixmap.
> >
> > Under Win32, it first tries the hardware accelerated offscreen rendering
> (NEW). If the extensions are not available, an Offscreen Device Context is
> used.
> >
> > The source code is in VTK/Rendering: vtkXOpenGLRenderWindow,
> vtkWin32OpenGLRenderWindow and the superclass vtkOpenGLRenderWindow.
> >
> > Kent Eschenberg wrote:
> >
> >> No fixes here - just some related info.
> >>
> >> --On 11/16/2006 02:55:05 PM +0100 biddisco at cscs.ch wrote:
> >>
> >>> I keep getting a warning that one or more of the servers cannot access
> >>> a display and so compositing will be disabled.
> >>>
> >> ...
> >>
> >>> It used to work ok, but I must have broken something. Anyone got any
> idea?
> >>>
> >> 1) Another possible cause is that something changed in your OS'
> defaults. Upgrades to some of our systems sometimes replaces various
> graphics header files.
> >>
> >> 2) You might try changing
> >>
> >>
> >>> and set environment to (also tried blank for DISPLAY)
> >>> DISPLAY :0
> >>>
> >> to instead set DISPLAY to localhost:0.0.
> >>
> >> 3) Using X Windows and using OpenGL are two different issues; linking t
> Mesa does not always eliminate the need to access X.
> >>
> >> For example, the code may ask X for a font definition that it uses to
> prepare the equivalent font in Mesa.
> >>
> >> There is also a bug (may not be on the formal list) where pvbatch (and
> maybe pvserver) still need to see an X server though they don't really use
> it.
> >>
> >> 4) Finally, keep in mind that there are 2 different types of "off
> screen rendering".
> >>
> >> The one that is officially known by that name has been in OpenGL from
> the beginning (see glXCreateGLXPixmap). It writes to an X pixmap instead of
> the screen (I suspect there is also a Windows version). I *think* this
> approach still uses the graphics card
> >> for acceleration.
> >>
> >> In addition, Mesa can render off screen, into a buffer, and does not
> need a graphics card or an X pixmap - it tries to hide all that from the
> application.
> >>
> >> Of course, all this is just a list of options; perhaps someone who
> knows the internals can comment on how VTK/ParaView actually does things???
> >>
> >> Kent
> >> Pittsburgh Supercomputing Center
> >>
> >
> >
> >
>
>
> --
> John Biddiscombe,                            email:biddisco @ cscs.ch
> http://www.cscs.ch/about/BJohn.php
> CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
> Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82
>
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/paraview/attachments/20061117/6826e6be/attachment.html