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.
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) 0,0.0,1. 0,1.0); results in a yellow pixel (should be purple) 0,1.0,0. 0,1.0); results in a purple pixel (should be yellow) 0,1.0,1. 0,0.5); results in a cyan pixel (should be semitransparent white)
gl_FragColor = vec4(1.
gl_FragColor = vec4(1.
gl_FragColor = vec4(1.
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: :ImageFormatARG B32 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.