1. 09 Sep, 2011 2 commits
  2. 07 Sep, 2011 1 commit
  3. 01 Sep, 2011 2 commits
  4. 23 Aug, 2011 1 commit
  5. 12 Jul, 2011 1 commit
    • miller86's avatar
      Resolving #631, removing 'using' statements from all header files. · ace3d1e1
      miller86 authored
      As a consequence, a lot of source files needed fixing up too. There
      were many cases where source files referred to STL classes but either
      did not include the cooresponding C++ STL header or did not have a
      using statement or did not have a 'std::' scope resolution.
      I added a hook to prevent commits of header files with using statements
      in them. I added skips for anything in vendor_branches, release and
      src/third_party_builtin and common/utility/visitstream.h (whose using
      statements I think define a single symbol name such as cerr or endl).
      Nonetheless, I still think visitstream.h might bare further scrutiny
      on this issue.
      There are a number of other observations I had regarding header file
      design and usage that I will send to visit-developers in a follow-up
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@15352 18c085ea-50e0-402c-830e-de6fd14e8384
  6. 14 Jun, 2011 1 commit
  7. 10 Jun, 2011 1 commit
  8. 18 May, 2011 2 commits
  9. 18 Jan, 2011 1 commit
    • brugger's avatar
      · b22d9fd2
      brugger authored
      I updated the copyright dates in the copyright notice in all the "*.c",
      "*.C", "*.h", "*.java", "*.cmake", "*.txt" and "*.in" files in the "src"
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@13578 18c085ea-50e0-402c-830e-de6fd14e8384
  10. 13 Jan, 2011 1 commit
  11. 27 Aug, 2010 1 commit
  12. 26 Aug, 2010 1 commit
  13. 24 Aug, 2010 1 commit
    • pugmire's avatar
      This provides an option to improve performance for datasets with a lot of... · 9a39ae23
      pugmire authored
      This provides an option to improve performance for datasets with a lot of domains, located in Options/Rendering/Advanced  "Compact domains on engine".
      It has three settings, Never, Always and Auto, with threshold.
      The base problem is a performance issue in how vtkRenderer handles the list of vtkActors. 
      For the particular case I was looking at, with 25000 domains, when not in SR mode, there was around a 25 second delay in the viewer while vtkActors were allocated and de-allocated.  This option allows control over how domains on the engine are appended together to reduce the number of actors created. The downside, of course, is that the memory footprint increases because the engine output geometry is appended together into unstructured meshes.
       The default is to never do any appending.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@12282 18c085ea-50e0-402c-830e-de6fd14e8384
  14. 21 Aug, 2010 1 commit
  15. 20 Jul, 2010 1 commit
    • brugger's avatar
      · a78ec05f
      brugger authored
      I updated the LLNL review and release number in the copyright notice
      in all the "*.C", "*.h", "*.java", "*.cmake", "*.txt" and "*.in" files
      in the src directory.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@11946 18c085ea-50e0-402c-830e-de6fd14e8384
  16. 30 Apr, 2010 1 commit
  17. 29 Mar, 2010 1 commit
  18. 16 Dec, 2009 2 commits
    • fogal1's avatar
      Detect failed window initialization. · 44baf8ac
      fogal1 authored
      Erase the window from the map, so we won't think it's created the
      next time around.  Rethrow any exception we might get; in many
      cases it will end up getting shipped back as an RPC response.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@9208 18c085ea-50e0-402c-830e-de6fd14e8384
    • fogal1's avatar
      Remove initial creation of window 0. · 4a3355bb
      fogal1 authored
      We'll do it dynamically when required.  This has the effect of
      delaying the window initialization, decoupling it from the rest of
      the engine's initialization.  Thus, when we do get around to
      initializing the window, we'll be in a better position for both
      detecting and reporting errors, because we can rely on the
      previous initialization of our error handling routines.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@9206 18c085ea-50e0-402c-830e-de6fd14e8384
  19. 25 Nov, 2009 1 commit
  20. 05 Nov, 2009 1 commit
    • whitlocb's avatar
      I could not get around build problems related to rendering_visit_vtk depending · 1b475a32
      whitlocb authored
      on avtPlotter on my cmake branch due avt::glew::initialize. I'm not using 
      -unresolved,dynamic_lookup for gcc which lets the linker skip unresolved 
      symbols. I find this is a good test for measuring compatibility with Windows, 
      which is our most strict platform. CMake dependencies will need to remain strict
      to ensure that the code continues to build on Windows.
      The problem is where to put avt::glew::initialize. Since it relies on
      state from avtCallbacks, it makes sense to keep it in avt. This is why I did
      not move avt::glew::initialize into rendering_visit_vtk. Anyway, I decided to
      move rendering_visit_vtk and parallel_visit_vtk into the avtPlotter library 
      itself so the vtkMappers can use avt::glew::initialize without introducing bad
      library dependencies. Plot plugins also use avt::glew::initialize but, as plots,
      they already have avtPlotter dependencies so it's okay. Moving 
      parallel_visit_vtk also helps with a library dependency problem for parallel.
      If I remember correctly, it had a dependence on avtPipeline. Coupled with
      Makefile LIBS= updates we can now build in parallel without the 
      -unresolved,dynamic_lookup options on the Mac.
      While I was at it, I removed the engine/parstate library, moving MPIXfer into
      the engine. The other part of engine/parstate was deprecated in 1.12.0 so the
      library did not have much reason to exist.
      Not much is different from a Linux point of view other than we have 3 fewer
      libraries now.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@8845 18c085ea-50e0-402c-830e-de6fd14e8384
  21. 04 Aug, 2009 1 commit
    • brugger's avatar
      · 546e8915
      brugger authored
      1) I changed the year in the copyright notice from 2008 to 2009 in a
         bunch of files. A total of 5231 files were changed.
      2) I corrected the LLNL review and release number in the copyright notices.
         It turns out I transposed 2 of the digits in many of the files when I
         originally put the new copyright notice in.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@8045 18c085ea-50e0-402c-830e-de6fd14e8384
  22. 22 Jul, 2009 2 commits
  23. 20 Jul, 2009 1 commit
    • fogal1's avatar
      Make transparency cache invalidation smarter. · db5ac4ad
      fogal1 authored
      First, move the relevant component to the beginning RenderSetup
      instead of Render.  This allows it to be shared instead of
      duplicated in the IceT code path.  Secondly, don't invalidate the
      cache twice; we still force it to be calculated at the end of
      RenderSetup, but if it so happens that it was calculated during
      setup, it's OK (and much faster) to use the cached value.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7849 18c085ea-50e0-402c-830e-de6fd14e8384
  24. 17 Jul, 2009 1 commit
  25. 17 Jun, 2009 2 commits
  26. 28 May, 2009 2 commits
    • fogal1's avatar
      Invalidate the transparency cache earlier. · c3c6e49c
      fogal1 authored
      In some cases, we'd render earlier than expected, before getting
      through RenderSetup.  The cache would be at it's old value then
      (except on first renderings!), and wouldn't know to recalculate.
      By invalidating here, we'll force this to get recalculated if some
      code needs to know about transparencies before RenderSetup
      AFAICT, this also means that `simple' re-renders, such as rotating
      the volume, will cause the calculation (and ensuing global
      communication) to occur.  This is undesirable, but no worse than a
      week ago.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7441 18c085ea-50e0-402c-830e-de6fd14e8384
    • fogal1's avatar
      Make an image dump happen sooner. · 90f0665f
      fogal1 authored
      It was giving misleading results before.  We were dumping images
      after we did our opaque composite, but also after we'd broadcast
      out the resultant image to image-less nodes.  This meant that
      nodes that didn't render anything looked as if they rendered the
      entire volume.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7440 18c085ea-50e0-402c-830e-de6fd14e8384
  27. 27 May, 2009 1 commit
  28. 25 May, 2009 1 commit
    • fogal1's avatar
      Do ad hoc memoization of the transparency calculation. · d7c4a728
      fogal1 authored
      In some SR mode configurations, we have the issue that rendering
      will involve global communication due to the need to sort
      transparent geometry.  This is undesirable because 1) we don't
      know the sort order until rendering is underway, thus preventing
      us from using that knowledge for more intelligent compositing, and
      2) certain compositors, such as IceT, do not call our render
      method synchronously in all cases, leading to deadlock in the
      worst case.
      This commit changes the transparency actor so that it keeps an
      internal cache of the transparency calculation.  Clients are now
      expected to clear ("Invalidate") the cache periodically.  In SR
      mode we'll do that once per render.  In standard rendering modes,
      we'll invalidate the cache every time we add a plot to the window.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7402 18c085ea-50e0-402c-830e-de6fd14e8384
  29. 04 May, 2009 1 commit
  30. 06 Apr, 2009 1 commit
  31. 12 Mar, 2009 1 commit
  32. 13 Feb, 2009 1 commit
  33. 03 Feb, 2009 1 commit