1. 08 Sep, 2015 1 commit
    • Dan Lipsa's avatar
      BUG: OSMESA configuration flags can cause link errors. · 3b6810ff
      Dan Lipsa authored
      This fixes:
         VTK_OPENGL_HAS_OSMESA on
         VTK_USE_X             on
         caused link errors in Rendering/OpenGL as some of the cxx
         files contained code ifdef using VTK_OPENGL_HAS_OSMESA instead of
         VTK_USE_OSMESA
      
      In the past, one could link against both MESA and OSMESA and use OSMESA only
      for off-screen rendering. In recent versions of MESA this is not the case anymore.
      3b6810ff
  2. 31 Aug, 2015 1 commit
    • Dan Lipsa's avatar
      COMP: Add logic to selectively use OpenGL or OSMesa. · f09903e4
      Dan Lipsa authored
      Use vtkOpenGL.cmake to decide to use (LINK_PRIVATE) OpenGL or Offscreen Mesa.
      OpenGL is now LINK_PRIVATE, so additional libraries and tests need to include OpenGL.
      Include the following in your CMakeLists.txt:
      
      include(vtkOpenGL)
      vtk_opengl_link(${module})
      
      for every ${module} that uses OpenGL. This takes care of include directories and
      linking of proper libraries.
      f09903e4
  3. 24 Aug, 2015 2 commits
  4. 20 Aug, 2015 2 commits
    • Brad King's avatar
      ENH: Remove use of include <vtksys/ios/*> and vtksys_ios::* · 3ae7dd3a
      Brad King authored
      We no longer need this compatibility layer for the compilers we support.
      Use the following commands to switch to standard header and namespace:
      
       git grep -l vtksys/ios/ | xargs sed -i 's|vtksys/ios/||'
       git grep -l vtksys_ios | xargs sed -i 's|vtksys_ios|std|g'
      3ae7dd3a
    • Brad King's avatar
      ENH: Remove use of include <vtksys/stl/*> and vtksys_stl::* · eaf0f6ac
      Brad King authored
      We no longer need this compatibility layer for the compilers we support.
      Use the following commands to switch to standard header and namespace:
      
       git grep -l vtksys/stl/ | xargs sed -i 's|vtksys/stl/||'
       git grep -l vtksys_stl | xargs sed -i 's|vtksys_stl|std|g'
      eaf0f6ac
  5. 03 Aug, 2015 1 commit
  6. 22 Jul, 2015 1 commit
    • Bill Lorensen's avatar
      STYLE: Replace vtksys_stl and vtksys_ios:: with std:: · 924248d9
      Bill Lorensen authored
      In the early days of VTK, support for stl was not portable. vtksys_stl
      and vtksys_ios provided a portable implementation of the stl. Now, all
      of the VTK supported compilers have portable stl implementations.
      
      This patch:
        1) Replaces the vtksys_ios:: with std::.
        2) Replaces the vtksys_stl:: with std::.
        3) Removes "using" statements for stl
      924248d9
  7. 07 Jul, 2015 1 commit
  8. 01 Jun, 2015 1 commit
  9. 14 May, 2015 2 commits
    • Ken Martin's avatar
      bc47058c
    • David C. Lonie's avatar
      Add vtkWindow::DetectDPI. · c8d65517
      David C. Lonie authored
      Auto-detecting the screen DPI (which the win32 backend does)
      interferes with testing after we make 2D text rendering
      DPI-aware. Since only one backend supported automatic DPI
      detection, I moved this out into a user method so that folks
      who depend on this behavior can still have it, but we can
      test consistently.
      c8d65517
  10. 06 May, 2015 1 commit
  11. 09 Apr, 2015 3 commits
  12. 06 Apr, 2015 2 commits
  13. 26 Mar, 2015 1 commit
    • Sean McBride's avatar
      Fixed memory leak in Cocoa code (regression) · acf0c227
      Sean McBride authored
      I accidently added a memory leak when adding partial ARC support.
      I forgot that one can build as mixed GC+MRR, in which case the
      explicit retain/release calls are needed, so added them back.
      acf0c227
  14. 25 Mar, 2015 1 commit
  15. 16 Mar, 2015 2 commits
  16. 02 Mar, 2015 1 commit
  17. 26 Feb, 2015 1 commit
  18. 20 Feb, 2015 1 commit
    • Julien Finet's avatar
      Kill TDX timer when using no WindowHandle · ed304209
      Julien Finet authored
      From KillTimer(HWND hWnd, UINT_PTR uIDEvent) documentation:
      uIDEvent [in]: The timer to be destroyed. If the window handle passed to
      SetTimer is valid, this parameter must be the same as the nIDEvent value
      passed to SetTimer. If the application calls SetTimer with hWnd set to
      NULL, this parameter must be the timer identifier returned by SetTimer.
      
      Fixes #15334
      
      Change-Id: Ifd88c790f4955dcd352004e2f5cba22a900e02de
      ed304209
  19. 16 Feb, 2015 3 commits
  20. 13 Feb, 2015 1 commit
  21. 09 Feb, 2015 1 commit
    • Chris Harris's avatar
      Wait for resize notification in SetSize(...) · 39fedcd6
      Chris Harris authored
      Calling XSync(...) is not enough. This causes a timing issue
      went SetSize(...) is called following be a Render(...). In
      Render(...) the window is queried for the window size which
      will not have be resize yet so we get the old size! ( seen
      particularly in vtkWeb ). Add loop to wait for ConfigNotify
      event with the new size.
      
      Change-Id: I72d34cae16215b6887467496df23d7a8e0bdcd37
      39fedcd6
  22. 03 Feb, 2015 1 commit
  23. 19 Jan, 2015 1 commit
  24. 14 Jan, 2015 1 commit
  25. 18 Dec, 2014 3 commits
  26. 16 Dec, 2014 1 commit
    • Sean McBride's avatar
      Refactoring and cleanup of Cocoa NSWindow and NSView observations · 141198ec
      Sean McBride authored
      Now only perform observation at all if it was VTK that created the NSWindow/NSView.
      This avoids receiving many NSView frame change messages when not needed.
      
      Some renaming, new asserts, fix minor type mismatch.
      Things are more symmetrical now.
      
      Change-Id: I337afef3a07fe9e33abdfc6e7e714502262bcc91
      141198ec
  27. 12 Dec, 2014 1 commit
    • Utkarsh Ayachit's avatar
      Disable OpenGL error checks in release builds. · f1a90fd2
      Utkarsh Ayachit authored
      OpenGL error checks have been shown to affect performance dramtically
      when rendering large datasets. That being the case, this change adds a
      new flag which disables these checks in Release builds, by default.
      Users can still use the advanced variable
      VTK_REPORT_OPENGL_ERRORS_IN_RELEASE_BUILDS to enable checks in release builds as well.
      
      Change-Id: Ib7a46292fcbc9dd166dbbd6d9217ee71f98f14df
      f1a90fd2
  28. 11 Dec, 2014 2 commits
    • Cory Quammen's avatar
      Enable coloring by indexed lookup for vtkStringArrays · 94498364
      Cory Quammen authored
      This change makes it possible to map vtkStringArrays to colors using
      indexed lookup mode. The vtkStringArrays may be associated with
      points, cells, or neither (field data). A slew of changes were
      required to give this capability:
      
      - Changed signature of vtkScalarsToColors::MapScalars(...) and
        vtkDiscretizableColorTransferFunction::MapScalars(...)  to take a
        vtkAbstractArray instead of a vtkDataArray. This enables mapping
        non-vtkDataArray arrays, such as vtkStringArrays. These changes are
        backwards compatible because vtkAbstractArray is the parent class of
        vtkDataArray.
      
      - Changed vtkLookupTable::MapScalarsThroughTable2(...) to handle
        vtkStringArrays.
      
      - Changed vtkColorTransferFunction::MapScalarsThroughTable2(...) to handle
        vtkStringArrays.
      
      - Added vtkAbstractMapper::GetAbstractScalars(...) that returns a data
        array as a vtkAbstractArray - needed to retrieve vtkStringArray
        scalars.
      
      - Added some error reporting when unhandled array type is encountered
        in vtkScalarsToColors::MapScalarsThroughTable2.
      
      - Enabled use of vtkStringArrays for coloring in the surface mappers.
      
      - Added some tests for mapping vtkStringArrays with
        vtkColorTransferFunction and vtkDiscretizableColorTransferFunction.
      
      - Added some tests for coloring objects by vtkStringArrays in cell data
        and point data.
      
      - Added logic to vtkMapper and vtkPolyDataMapper2D that generates a
        reasonable default lookup table when a vtkStringArray or other
        non-numeric array is selected for coloring by scalars. This requires
        making the vtkRenderingCore module depend on vtkCommonColor. Added
        tests for this feature.
      
      Change-Id: I91e2e451217139a7daabd7f4a63de0b8ff707ad4
      94498364
    • Cory Quammen's avatar
      Handle coloring by field data · a07731a2
      Cory Quammen authored
      Some level of support was previously available for coloring by field
      data, but this was restricted to drawing triangle strips. This patch
      adds another mode to coloring by field data that enables coloring the
      entire data set by a particular tuple in the field data. The field
      data tuple gets mapped through the color map, and that color is used
      to color the entire data set. The default behavior for triangle strips
      is retained by setting this tuple index to -1, the default value.
      
      The motivation for this change is to make it possible to color blocks
      in a multi-block dataset according to a value in that block's field
      data array, e.g., an initial condition, block ID, etc. Vector values
      (arrays with more than one component) are fully supported.
      
      Several other improvements were also made:
      
      - Added test for existing capability of coloring by field data.
      
      - Added test for coloring by tuple of field data.
      
      - Modified vtkMapper::GetScalarModeAsString() to return
        string for field data scalar mode.
      
      - Fixed vtkDataSetSurfaceFilter::UnstructuredGridExecute(...) and
        vtkUnstructuredGridGeometryFilter::RequestData(...)
        to pass field data through to output
      
      Change-Id: I0d97e84ec77e7ea01ca1b1350acce73cb6c4c15b
      a07731a2