Skip to content
Snippets Groups Projects
  1. Mar 20, 2017
  2. Mar 17, 2017
  3. Feb 24, 2017
  4. Dec 15, 2016
  5. Dec 12, 2016
    • David Gobbi's avatar
      16920: Mark vtkPainterCommunicator as not wrappable · 714d8e60
      David Gobbi authored
      The header for vtkPainterCommunicator was not listed in CMakeLists.txt,
      and since the wrappers had no knowledge of it, the wrappers assumed that
      it was a vtkObjectBase-derived class from a different module.  Hence any
      methods that accepted a "vtkPainterCommunicator *" parameter were
      wrapped incorrectly and would segfault when called.
      714d8e60
  6. Dec 09, 2016
  7. Dec 08, 2016
    • Ken Martin's avatar
      Some openvr related bug and performance fixes · 0203dc6d
      Ken Martin authored
      There was a vsync issue that could cause significant performance
      issues and jitter in the VR display that was fixed.
      
      A sync point in the SaveGLState code was moved into
      External/vtkExternalOpenGLRenderWindow as that is the class
      that needs it.  A couple other minor performance improvements.
      0203dc6d
  8. Dec 07, 2016
  9. Dec 05, 2016
    • David Gobbi's avatar
      Avoid expanding macro _WCHAR_T_DEFINED · 140ba599
      David Gobbi authored
      Apparently expansion of this macro (which is sometimes defined on Win32)
      is undefined and causes a compile error.
      140ba599
    • David Gobbi's avatar
      Add many more predefined wrapper macros · 0f81b721
      David Gobbi authored
      This is mainly for kwiml, which was added to VTK 7.1.  For type sizes,
      endianness, etc. kwiml checks compiler macros instead of using cmake
      to generate config headers via try-compile.  Hence, the wrappers must
      define all the macros that the native compiler defines.
      0f81b721
  10. Dec 04, 2016
  11. Dec 03, 2016
  12. Dec 01, 2016
    • David Gobbi's avatar
      Make WRAP_DEPENDS from DEPENDS and PRIVATE_DEPENDS · 98f45e95
      David Gobbi authored
      In VTK 6.1 the PRIVATE_DEPENDS section was added to the module.cmake files,
      in order to reduce linking.  This created a problem for the wrappers that
      went unnoticed at the time: when a VTK interface method takes or return a
      pointer to a VTK object, a simple forward declaration and private linkage
      of the library defining that object is sufficient for C++.  But for the
      wrappers, it is insufficient because the wrappers require the definitions
      of any types that are used as method parameters, otherwise they cannot
      know whether a forward-declared class is derived from vtkObject or not.
      
      For VTK 7.1 the module.cmake files were cleaned up and many dependencies
      were moved from DEPENDS to PRIVATE_DEPENDS.  This cleanup caused the
      bug that was introduced in VTK 6.1 to become apparent, because suddenly
      a whole bunch of methods were not longer wrapped in Java because the
      wrappers could not reliably determine whether forward-declared types
      were derived from vtkObject or not.  Tcl and Python continued to work
      because they are less strict in their type checking.
      98f45e95
    • David Gobbi's avatar
      Expand typedefs for the Tcl and Java wrappers · 858c6ed5
      David Gobbi authored
      Even though typedefs have been handled by the Python wrappers ever since
      VTK 6.0, this feature was never enabled for the Java and Tcl wrappers.
      This problem was noticed when the vtkMTimeType typedef was introduced,
      since it caused MTime methods to disappear from the Java/Tcl wrappers.
      858c6ed5
  13. Nov 14, 2016
  14. Nov 12, 2016
  15. Nov 11, 2016
  16. Nov 10, 2016
Loading