[Paraview] Paraview on a tiled display

[Randall Hand]

Bounding box fix verified :) works great..

As for the restart issue, I'm still seeing it.  I've basically resigned
myself to putting a 'rm -f ~/.ParaViewrc' in my starting scripts. I'll keep
investigating it here.

On 8/9/06, Moreland, Kenneth <kmorel at sandia.gov> wrote:
>
>  I've checked in a fix (and a regression test) for the bounding box issue
> this morning.  It should be working now.
>
>
>
> As for your restart issue, I am not able to replicate it.  The rendering
> speed looks consistent to me on restarting ParaView.
>
>
>
> -Ken
>
>
>   ------------------------------
>
> *From:* Randall Hand [mailto:randall.hand at gmail.com]
> *Sent:* Tuesday, August 08, 2006 10:13 AM
> *To:* Moreland, Kenneth
>
> *Cc:* Paraview List
> *Subject:* Re: [Paraview] Paraview on a tiled display
>
>
>
> Ok, I just got it compiled and here's what I see.
> 1) Mullions work.  Yipee!
> 2) The ScalarBar issue I reported yesterday, no longer happens (stays
> right where it's supposed to).. Yipee!
> 3) I see the Ordered Compositing checkbox now (wasn't in the 2.4.4 build I
> made)
> 4) Some of the progressbar updates don't come through now.. It's a minor
> thing, but a bit odd.  Makes it look like it's locked up at times.
> 5) I no longer get bounding boxes on the client like I used to.. My client
> shows nothing but crosshairs.
> 6) I still have issues with paraview being extremely slow on a restart.
> Although, I've made progress.
>        1) Run Paraview.. Turn on Triangle Strips & Turn off Immediate
> mode.  Everything is fine & dandy, 1s refresh rates.. Shutdown
>        2) Start paraview again, verify all options (Including Client
> Collect now) are preserved.  See the 6-7s refresh times.
>        3) Turn on Immediate Mode, wait for Redraw.. Turn off Immediate
> Mode, wait for redraw.
>        4) Witness the restored 1s refresh rates.
>    So it seems that perhaps these options aren't being propagated to the
> nodes at startup like they should be.
>
> So if I can get my bounding boxes back, and we can get the restart issue
> thing figured out... I'ld be happy :)
>
> On 8/8/06, *Moreland, Kenneth* <kmorel at sandia.gov> wrote:
>
> Randall,
>
>
>
> I've incorporated your changes into the ParaView trunk and checked it in.
> If you can, please check it out and make sure it works for you.  I also
> think the issues you are having with client collect have been fixed on the
> trunk (vtkPVIceTRenderModuleUI.cxx 1.15).  It would be nice to know you
> are having problems before 2.6 gets released.
>
>
>
> -Ken
>
>
>   ------------------------------
>
> *From:* paraview-bounces+kmorel=sandia.gov at paraview.org [mailto:
> paraview-bounces+kmorel=sandia.gov at paraview.org] *On Behalf Of *Randall
> Hand
> *Sent:* Friday, August 04, 2006 2:05 PM
> *Cc:* Paraview List
>
>
> *Subject:* Re: [Paraview] Paraview on a tiled display
>
>
>
> Attached to this email, find the diff patchfile of the Servers directory
> (the only directory affected by this change).  From my testing here it seems
> to work great.  Took a little while to get the mullions computed correctly
> during the subsampled rendering, but it seems to work now.
>
> The one issue I've been unable to figure out is that, for an unknown
> reason, the Client Collect gets mangled when Mullions are Enabled.  I've
> looked all over the place and I can't figure out how this parameter gets
> passed around.  When starting paraview the parameter is read correctly from
> the .ParaViewrc and properly used, but when it's written back to the
> .ParaViewrc file it's mangled (Originally it was writing it as 43676546, and
> now after a full recompile it's writing it as 6, when both times it should
> be 100).  Also, when it comes in mangled like that, of course the first
> thing I do is reset it to 100.  Unfortunately, the rendering is
> significantly slower, as if it's still computing the reduced geometry &
> transmitting it to the client (Although the client does not render it).
> Manually resetting the parameter in the .ParaViewrc & restarting paraview
> fixed it (for that 1 run).
>
> Any ideas?
>
> On 8/4/06, *Randall Hand* < randall.hand at gmail.com> wrote:
>
> Ok, with the info from Kenneth, I made the change and it's working great!
>
>
> So, how should I return this patch back to you?  I just tried doing a
> 'diff -Naur' to generate a patch for you, but it started including almost
> every single file.  Seems an "out of core" build isn't completly "out of
> core" afterall.
>
> On 7/28/06, *kmorel* < kmorel at sandia.gov> wrote:
>
> > But is there any way to account for the Bezel width?  Is there any
> > configurable parameter to define a "gap" between tiles?
>
> This request is already captured as bug #1132:
> http://www.paraview.org/Bug/bug.php?op=show&bugid=1132&pos=1
>
> This actually should not be too hard to implement since the underlying
> parallel rendering code already supports mullions.  It's just a matter of
> adding some new parameters to pvserver and spacing the tiles out
> differently.
>
> This bug has been on my to-do list for, gosh, over a year now.  But, since
> we rarely use tile displays anymore and the tile displays that we do have
> don't have any spaces or overlap, this has been the lowest priority and I
> never get to it.
>
> If someone would like to implement this (hint, hint) and make sure
> everything (rendering and annotation) is working correctly, I am perfectly
>
> happy to point to the correct sections of code to change.
>
> -Ken
>
>
>
>
> --
> ----------------------------------------
> Randall Hand
> Visualization Scientist
> ERDC MSRC-ITL
>
>
>
>
> --
> ----------------------------------------
> Randall Hand
> Visualization Scientist
> ERDC MSRC-ITL
>
>
>
>
> --
> ----------------------------------------
> Randall Hand
> Visualization Scientist
> ERDC MSRC-ITL
>



-- 
----------------------------------------
Randall Hand
Visualization Scientist
ERDC MSRC-ITL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/paraview/attachments/20060809/2627eb14/attachment.htm