Re: [Chromium-dev] Re: Pixel-image compression within Chromium?

[Brian P. <bri...@tu...>]

I checked in your patch, Bill.  Thanks!

-Brian


Bill Feth wrote:
> Hi Brian,
> 
> I worked with Alicia to fix the byte-swapping problem she was seeing. The
> code in packer/pack_swap_texture.c was not byte swapping the texture data
> when it was sent from a little-endian app-node to a big-endian crserver.
> 
> She had a test application that used gluBuild2DMipmaps, which converted
> the UNSIGNED_BYTE texture to UNSIGNED_SHORT and then generated
> UNSIGNED_SHORT mipmap levels. None of the texture data was being
> byte-swapped by Chromium. The top mipmap level looked fine because the
> pixel values were all values like 0xA0A0 and 0xB7B7 (an artifact of the
> byte->short conversion). But the mipmap levels were mostly values like
> 0xB7FC, which look very wrong when they are not swapped.
> 
> I have attached a patch; it utilizes byte-swapping code recently added to
> util/pixel.c for handling GL_(UN)PACK_SWAP_BYTES. I've tested that it at
> least works in the Windows->IRIX direction for 2D textures, but it should
> apply to more general cases.
> 
> Would you be able to review and apply the patch?
> Thanks,
> Bill
> 
> 
> -----Original Message-----
> Date: Fri, 14 Jan 2005 07:40:18 -0700
> From: Brian Paul <bri...@tu...>
> To: aac...@ad...
> CC: chr...@li...
> Subject: [Chromium-dev] Re: Pixel-image compression within Chromium?
> 
> 
> Do you suspect it's texture images that are the source of the problem? 
>   Or glDrawPixels?  You mentioned images in your post.
> 
> Textures are typically specified in GL_RGB or GL_RGBA format with
> GLubytes.  Since those are byte-sized components, there shouldn't be any
> endian issues.
> 
> If you see the problem with any small, simple GL demos (like the redbook
> or GLUT demos) that would help narrow it down.  Even a screen shot showing
> the problem could give us a clue.
> 
> Chromium doesn't normally do any image compression.
> 
> -Brian
> 
> 
> aac...@ad... wrote:
> 
>>Hello,
>>
>>I posted something about this problem before, but have not gotten any
> 
> response.  To re-iterate, certain colors on certain applications run
> through Chromium from a Windows Box (mothership and crappfaker) to a
> crserver running with OMP (like DMX) on an SGI Onyx 4 running IRIX do not
> appear correctly.   
> 
>>One problem is that the Chromium Print-SPU doesn't include data in its
> 
> output; only the address of the texture image in memory, so I can't see
> the data that the application's sending to Chromium.
> 
>>For those of you who know the inner workings of Chromium, is it 
>>possible
> 
> that Chromium is doing some kind of pixel-image compression, and there are
> bit errors being introduced because of that?  If it does do pixel-image
> compression, is it possible to turn this compression off??
> 
>>Thanks for your help,
>>Alicia