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

[Bill F. <fe...@sg...>]

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