Re: [Chromium-dev] Chromium and ParaView 2.0.1

[Joel W. <we...@st...>]

A bit of further info on this: ParaView is calling Chromium with a variety of 
bytes_per_row values and payload lengths, nonzero skipRows and skipPixels, 
various strides equal to bytes_per_row, and alignment=4:

Case 2; payload_len= 146680,bytes_per_row= 760, rows= 193, alignment= 4, 
skipRows= 90, skipPixels= 35, stride= 760
Case 2; payload_len= 156024,bytes_per_row= 788, rows= 198, alignment= 4, 
skipRows= 24, skipPixels= 12, stride= 788
Case 2; payload_len= 265144,bytes_per_row= 1012, rows= 262, alignment= 4, 
skipRows= 24, skipPixels= 0, stride= 1012
(and many more)

The previous version of ParaView (which works with Chromium) does only the 
'doesn't need special packing' case of the if in packspu_neet.c:packspuReadPixe
ls(), except for a few calls to the 'need special packing' clause with much 
simpler parameters:

Case 2; payload_len= 160000,bytes_per_row= 800, rows= 200, alignment= 4, 
skipRows= 0, skipPixels= 0, stride= 800

I'm not sure there is anything to be drawn at that point, in fact, so even 
that call might be broken.

we...@st... said:
> 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:packspuReadP
> ixels().   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