Gradients w/o BGRA_PRE

[Michael Heinrichs]

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 <james.graham at oracle.com> 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 <james.graham at oracle.com> 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
>>>>> 
>>>