Comment 14 for bug 1591727

Revision history for this message
In , Marcus Comstedt (marcus-mc) wrote :

User Agent: Mozilla/5.0 (X11; Linux ppc64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16
Build ID: 20130224111411

Steps to reproduce:

View a page with a WebGL canvas, using Firefox 19 on Linux/PPC.

Actual results:

The wrong colours appeard.

Example:

gl_FragColor = vec4(0.0,1.0,1.0,1.0); results in a transparent pixel (should be cyan)
gl_FragColor = vec4(1.0,0.0,1.0,1.0); results in a yellow pixel (should be purple)
gl_FragColor = vec4(1.0,1.0,0.0,1.0); results in a purple pixel (should be yellow)
gl_FragColor = vec4(1.0,1.0,1.0,0.5); results in a cyan pixel (should be semitransparent white)

Since the order of the components have been completely reversed, this looks like an endianness issue, and I saw several places in the code which seemed to assume that gfxASurface::ImageFormatARGB32 actually meant BGRA (not necessarily true, since it's supposed to use native endianness).

Expected results:

The actual colours requested by the fragment shader should have been displayed.