Gradients w/o BGRA_PRE

Jim Graham james.graham at oracle.com
Mon Feb 23 19:58:08 UTC 2015


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
>>>>
>>


More information about the openjfx-dev mailing list