[Paraview] Paraview on a tiled display

Moreland, Kenneth kmorel at sandia.gov
Wed Aug 9 10:18:20 EDT 2006


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
<mailto: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 <mailto: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/20060809/12e5a3cb/attachment-0001.html


More information about the ParaView mailing list