Re: Chromium and ParaView 2.0.1

Hey folks;
  I believe my ReadPixels problem (see below for old email) is arising in the 
neighborhood of the '#if 0'd code in packspu_net.c:packspuReadPixels().  
Brian, your revision 1.16.2.7 of that file file suggests that maybe this 
routine isn't robust yet, but since I don't understand most of the fields of 
CRPixelPackState I'm not sure.  The new version of ParaView which is causing 
the problem has odd-numbered x and y origins for the rectangle to be read, so 
I'm guessing that that might produce an alignment issue.  I have established 
that execution passes through the 'need special packing' clause of the routine.
  Does anyone know if this clause is trustworthy?

Thanks,
-Joel

> Joel Welling wrote:
> >>Joel Welling wrote:
> >>
> >>>Hi folks;
> >>>  Is anyone else running ParaView 2.0.1 through Chromium?  I am trying to get 
> >>>this together on our vis cluster, and there are problems with the ReadPixels 
> >>>of the sub-images from the various render servers for compositing (by Ice-T in 
> >>>ParaView) to make the whole image.  The sub-images look like they are being 
> >>>read back at the wrong resolution, such that adjacent pixels in the rendered 
> >>>image are not adjacent in the read-back image.
> >>
> >>Are you running a basic tilesort configuration or is there something 
> >>else going on?
> > 
> > 
> > It's a simpler configuration than that- just a single pack SPU sending to a 
> > render SPU (or a print SPU followed by a render SPU).  Brian, I'll forward the 
> > config file to you under separate mail.  We use it basically to give the 
> > calling application access to a graphics card.
> 
> Hmmm, glReadPixels in the Pack SPU is pretty simple so I doubt the 
> problem is there.
> 
> 
> >>>  I've looked at the images rendered on the individual crservers, and they 
> >>>look just great.  This system did work with earlier versions of ParaView 
> >>>(specifically 1.6.3), so I've compared the OpenGL calls made by the two 
> >>>versions.  The older version reads back images starting at pixel (0,0) and 
> >>>including the entire rendered area, while the new version seems to try to save 
> >>>bytes by only reading back the parts of the image where it thinks stuff has 
> >>>been drawn.  This means that ReadPixels is not done with a corner at (0,0).  
> >>>I'm guessing that perhaps there is a problem with ReadPixels of sections of 
> >>>the rendered image which do not include that corner.
> >>
> >>The tilesort SPU tracks object bounding boxes but that's not used for 
> >>glReadPixels.  So I'm not sure why the coordinates are funny.
> >>
> > 
> > 
> > Note that the coordinate change is apparently due to a change in ParaView, not 
> > to any intervention on Chromium's part.  I think it is this change (between 
> > ParaView 1.something and ParaView 2.0.1) that is messing up our application.
> 
> I guess I'd talk to the ParaView folks at this point if I were you.
> 
> -Brian
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Chromium-dev mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chromium-dev




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20