Page MenuHomePhabricator

VTK does not support sharing of graphics resources (yet)
Closed, ResolvedPublic

Description

VTK does not support sharing of graphics resources (vtkProps/vtkActors) across multiple render windows (yet).

Thus, we need to manage multipe graphics resources within the mitk::Mappers.

Ideas:

  1. Add parameter BaseRenderer* to mitk::BaseVtkMapper3D::GetProp() and GetLabelProp() and make both protected (CAVE: picking seems to use these).
  2. Manage a hashmap with .first=renderer, .second={actor, mapper}
  3. Store the .second part in a template class, which observes the renderer and removes itself from the hashmap when the renderer is destructed.
  4. mitk::Mappers that use vtkProps/vtkActors for rendering should use this mechanism.

The most important mitk::Mapper to change is the SurfaceMapper.

Event Timeline

From the VTK-Mailing-List (found by Mathias):

On all platforms, there is a way to create an OpenGL context that
shares some OpenGL resources (texture objects, display lists, shader
programs) with another OpenGL context. But it is not supported by VTK
(yet). The API of vtkRenderWindow does not provide a mechanism to do
so. And it is not a trivial change in VTK.

http://www.vtk.org/pipermail/vtkusers/2008-November/098090.html

Further points from today's discussion:

  1. mitk::Mapper should implement an interface for allowing arbitrary data to be associated per BaseRenderer (Actors, Mappers, textures, shaders, also VTK independent objects (e.g. ImageMapper2D::RenderInfo))

For this, an internal class interface (e.g. BaseRendererLocalStorage) could be implemented, and individual mappers would implement concrete sub-classes of this interface, which store and give acces to all required data

  1. When turning visibility off for individual renderes, renderer specific resources (e.g. display lists) in mappers should be released (possibly temporarily)
  1. It should be possible to create, handle and display Geometry2DData (planes) independent from BaseRenderers
  1. Make sure that ImageMapper2D extracts/reslices images only once (for 2D and 3D)

To realize the data-association per render-window, the Mapper hierarchy could be extended by template parameters which specify the data class (MapperLocalStorage) to be associated. The default implementation of this class (DefaultMapperLocalStorage) would be empty. The new hierarchy would then look like this (extract):

MapperBase (formerly Mapper)

Mapper< class RenderWindowLocalStorage = DefaultMapperLocalStorage > : public MapperBase

Mapper2D< class RenderWindowLocalStorage = DefaultMapperLocalStorage > : public Mapper< class PerRenderWindow = DefaultMapperLocalStorage >

GLMapper2D< class RenderWindowLocalStorage = DefaultMapperLocalStorage > : public Mapper< class PerRenderWindow = DefaultMapperLocalStorage >

ImageMapper2D : public GLMapper2D< ImageMapper2DLocalStorage >

ImageMapper2DLocalStorage is a concrete example for data handled per render-window (e.g., everything which is currently stored by mitk::ImageMapper2D::RendererInfo)

Further point of discussion: The extraction of slices currently done in ImageMapper2D should be externalized, because it is not specific to this mapper but is also used e.g. by Geometry2DDataVtkMapper3D. It should also be possible to have multiple planes rendered simultaneously, which are not necessarily associated with a BaseRenderer instance.

Rendering of Geometry2D (planes)

  • Extraction of slices from volume data will be moved from ImageMapper2D to a new class SlicesExtractor
  • SlicesExtractor is independent of BaserRenderer, i.e. multiple planes can be displayed independent of 2D-RenderWindows (via instances of Geometry2DData)
  • SlicesExtractor could either manage ALL extracted slices (for all planes and all visible volume data), or somehow be associated with Geometry2D or Geometry2DData objects

Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.

Markus, can you have a look at this bug (it's a very old one :-) )?

(In reply to Jasmin Metzger from comment #5)

Markus, can you have a look at this bug (it's a very old one :-) )?

LocalStorages have been implemented years ago, this bug is fixed.