Gradients w/o BGRA_PRE

[Jim Graham]

My suggestion would be to add BYTE_RGBA_PRE to the PixelFormat enums and 
that ES2 claims it supports and have the gradient code then test for 
either BYTE_BGRA_PRE or BYTE_RGBA_PRE support and use the appropriate 
indices depending on the result...

			...jim

On 2/27/15 2:29 PM, Michael Heinrichs wrote:
> 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
>>>>>>
>>>>
>