1. 01 Aug, 2009 2 commits
    • fogal1's avatar
      Set HW/SW rendering for the callback. · e55527b8
      fogal1 authored
      Outside of the engine, we don't know how many displays we'll have,
      and which ones are hardware contexts.  External code (in
      particular the volume plot) would use this callback object to
      figure out what kind of renderers to create.
      So we ignore the existing configuration and set hw/sw rendering
      based on what we've figured out during initialization.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7997 18c085ea-50e0-402c-830e-de6fd14e8384
    • fogal1's avatar
      Add debug messages for display creation. · cd930796
      fogal1 authored
      Lets us easily figure out what kind of display gets created.  This
      information can be inferred from other messages, but I
      semi-recently tracked down a bug where two modules disagreed about
      this bit of state.  This would allow one to very easily notice
      when that occurs.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7996 18c085ea-50e0-402c-830e-de6fd14e8384
  2. 22 Jul, 2009 2 commits
  3. 20 Jul, 2009 2 commits
  4. 17 Jul, 2009 1 commit
  5. 02 Jul, 2009 7 commits
  6. 30 Jun, 2009 1 commit
  7. 27 Jun, 2009 1 commit
  8. 26 Jun, 2009 2 commits
  9. 25 Jun, 2009 1 commit
  10. 19 Jun, 2009 1 commit
  11. 18 Jun, 2009 1 commit
  12. 17 Jun, 2009 2 commits
  13. 15 Jun, 2009 1 commit
  14. 12 Jun, 2009 1 commit
  15. 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
  16. 27 May, 2009 3 commits
  17. 25 May, 2009 2 commits
    • 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
    • fogal1's avatar
      Minor formatting / alignment change. · b0804c78
      fogal1 authored
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7400 18c085ea-50e0-402c-830e-de6fd14e8384
  18. 04 May, 2009 2 commits
  19. 30 Apr, 2009 1 commit
  20. 24 Apr, 2009 2 commits
  21. 22 Apr, 2009 2 commits
  22. 14 Apr, 2009 1 commit
    • whitlocb's avatar
      I made the VisItInit functions handle -dv so GetVisItLauncher returns valid · e476cdea
      whitlocb authored
      results in all components. This required moving some libutility code to 
      libmisc, hence the large number of changes (new header files).
      I also modified the viewer so various properties were consolidated into a
      ViewerProperties object accessible from the base class. This simplifies book
      keeping of properties and makes them accessible to all subclasses.
      I used the new ViewerProperties mechanism to conditionally add new menu options
      to the popup menu that let the viewer launch gui, cli, or quit from the 
      popup menu.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@6869 18c085ea-50e0-402c-830e-de6fd14e8384