[Paraview] Paraview on a tiled display

[Randall Hand]

I just finished some more research and it seems that this glitch is not
related to the Change I made.

I just reverted back to a standard 2.4.4 compile (Straight from Source
downloaded from the website) and the problem persists.  If I delete my
.ParaViewrc, so I start fresh, then my 60+ million triangle dataset loads
and renders a still frame in about 1 second (Across my 12-screen
renderwall).   Once I close/kill paraview and restart it, however, the
Client Collect option has changed and rendering (No matter what I set it to)
takes about 5 seconds.  Looks like it's a legitimate bug in Paraview, or
some strange glitch in our cluster.  Any advice on tracing this down?

On 8/4/06, Randall Hand <randall.hand at gmail.com> wrote:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/paraview/attachments/20060807/1860832f/attachment.html