[Paraview] Is there any point to compiling with MPI but without offscreen rendering?

[Utkarsh Ayachit]

Sorry for joining this conversation late (let's just say, never
experiment with lousy email organizers). Let me explain the background
behind the various flags and options (sticking with Linux systems).

vtkOpenGLRenderWindow has 3 modes: (a) X-based render window with
renderings done in the onscreen frame buffers (b) X-based render
window with rendering done in an offscreen buffer (either FBO, or
pbuffers, and such), (c) non-xbased render window using OSMesa.  In
both, (a), and (b), we need X and hence we see an X window. However
depending on OpenGL drivers and Windowing system, (a) may end up
rendering where overlapping windows corrupt the rendered images, hence
(b) can be used to avoid such anomalies with overlapping windows.

VTK_USE_OFFSCREEN is pretty much a bogus flag as far as ParaView is
concerned. It is used in VTK to set the default value of
vtkRenderWindow::OffScreenRendering flag. I don't know why VTK decided
that this should be a CMake flag since users can change the setting at
run-time anyways, but that has been the case for ages.

--use-offscreen-rendering is ParaView's runtime argument that tells
ParaView to create offscreen render windows (either (b) or (c)) when
render windows are created. Whether (b) or (c) is chosen depends on
whether ParaView was built with OSMesa support (this is where the
VTK_OPENGL_HAS_OSMESA flag comes into play. VTK_USE_OSMESA, is an
internal variable and cannot be set using CMake, so we can just ignore
it for now).

So one basically switches between onscreen and offscreen rendering
(either using fbo/buffers or OSmesa) using the runtime flag. As I
mentioned, onscreen rendering has had issues with overlapping windows
with certain drivers, windowing systems. Hence we decided to use
offscreen rendering for screenshots to avoid corrupting the captured
image. That itself would cause problems on some other implementations
where FBOs/Pbuffers didn't work correctly, or when using fancy
representations with shaders etc, and hence we added the option to not
use offscreen rendering for screenshots in the Settings dialog.

So we have onscreen and offscreen rendering and what type of offscreen
rendering is used depends on whether we built with OSMesa. That was
the case for the longest time. Now, with Mesa 7.9, Mesa folks decided
that applications could no longer link against libOSMesa and libGL at
the same time. That means that we can no longer support onscreen and
offscreen with OSMesa in the same build of ParaView
(http://paraview.org/Wiki/ParaView_And_Mesa_3D). Of course, if someone
has ideas on overcoming this issue, I'm all ears.

Utkarsh

On Wed, Oct 17, 2012 at 11:51 PM, Orion Poplawski <orion at cora.nwra.com> wrote:
> On 10/09/2012 11:55 AM, Cook, Rich wrote:
>>
>> As a user, I would prefer a single compile which links against OSMesa
>> AND OpenGL AND MPI if they are available, but uses whatever the user
>> chooses at runtime.  This requires code logic to handle, with #ifdefs to
>> handle the case where some feature is not available at compile time, and
>> additional if/then statements in C to handle the user choice, but seems
>> doable and would vastly simplify compilation, installation and usage.
>> Thanks
>
>
> As a packager, I believe this is important to achieve as well.
>
>
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA/CoRA Division                    FAX: 303-415-9702
> 3380 Mitchell Lane                  orion at cora.nwra.com
> Boulder, CO 80301              http://www.cora.nwra.com
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview