Hi Jim, after disabling the test and switching the channels in insertInterpColor(), gradients are rendered correctly. It is a hack, but it works for now. :) Thanks for the hint.
The format supported by default in ES 2.0 is actually BYTE_RGBA and not INT_RGBA. I think it makes sense to use a byte array in both cases as you initially suggested. - Michael > On 23 Feb 2015, at 20:58, Jim Graham <[email protected]> wrote: > > Oh dear, it is a bit worse than that. The texture creation code doesn't even > have an enum constant to specify BYTE_RGBA_PRE. It has BYTE_BGRA_PRE (which > is used by this code with a byte array) and INT_RGBA_PRE (which would involve > more than simply index twiddling to support). > > So, if INT_RGBA was universally supported, the code could be refactored to > use that. If we have to do it conditionally, that could be done as well as I > said below, but it would involve factoring "how do we store these components > and into which array?" rather than just index twiddling... > > ...jim > > On 2/23/2015 11:53 AM, Jim Graham wrote: >> Ah, I see. I was looking at the code that uploaded the pixels which >> behaved as I described, but I didn't check the texture creation code, >> which does look like it will reject it as you indicate. >> >> It looks like insertInterpColor, which computes the image data for the >> texture from the gradient colors, could handle either BGRA or RGBA just >> by changing the indices it uses. Is RGBA universally supported on >> Linux/OGL2/D3D? If so, then we could switch to that. Otherwise we'd >> have to factor in conditional BGRA vs RGBA tests into the appropriate >> places (probably just remember which was supported by the >> ResourceFactory in the initGradientTextures() function and have the >> insert() function test and modify its indices as appropriate)... >> >> ...jim >> >> On 2/23/2015 1:51 AM, Michael Heinrichs wrote: >>> Hi Jim, >>> >>> thanks for your reply. Right now I do not see anything. >>> PaintHelper.initGradientTextures() eventually calls >>> ES2Texture.create(), which checks if the requested pixel format is >>> supported. This test fails in my case, because WebGL is ES2 only and >>> the extension is not supported. But when I disable this test and >>> pretend that BGRA is RGBA, I see exactly what you describe: the red >>> and the blue channel are swapped. >>> >>> Thanks, >>> Michael >>> >>> >>>> On 23 Feb 2015, at 00:55, Jim Graham <[email protected]> wrote: >>>> >>>> Hi Michael, >>>> >>>> What error are you seeing, or is it just rendering incorrectly? >>>> >>>> Looking at the code in ES2Texture.uploadPixels() it looks like ES2 >>>> might support BGRA via an extension. Perhaps we've only encountered >>>> platforms with that extension so far. Otherwise, if I read the code >>>> correctly it looks like we will just pretend the incoming data is in >>>> RGBA format, which would mean that the rendering would happen, but >>>> the red and blue components would be swapped. Is that what you are >>>> seeing? >>>> >>>> ...jim >>>> >>>> On 2/21/2015 5:06 AM, Michael Heinrichs wrote: >>>>> Hi, >>>>> >>>>> I am experimenting with JavaFX on top of WebGL. Right now I am stuck >>>>> implementing gradients, but maybe somebody from this list can help. >>>>> >>>>> WebGL usually does not support the pixel format BGRA_PRE. From my >>>>> understanding, the ES2 renderer should work with such a >>>>> configuration, too. But when I try to use a gradient, at some point >>>>> PaintHelper.initGradientTextures() is called, which requires the >>>>> pixel format BGRA_PRE Obviously something about my configuration is >>>>> wrong. But I cannot figure out, where the alternative implementation >>>>> resides. How should the implementation of gradients work if BGRA_PRE >>>>> is not available? >>>>> >>>>> Thanks, >>>>> Michael >>>>> >>>
