[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradien
From:       Erik De Rijcke <derijcke.erik () gmail ! com>
Date:       2016-09-29 8:59:47
Message-ID: CABO6FzSmuqyu9VCA831TWvHZUUNzi5seKHfqXA4FH1j2aF1A8w () mail ! gmail ! com
[Download RAW message or body]

I filed a report but it seems to be under review(?).

On Wed, Sep 28, 2016 at 6:06 PM, Kevin Rushforth <kevin.rushforth@oracle.com
> wrote:

> I don't find a bug relating to this, so it seems the bug was never filed.
>
> Can you please file one?
>
> Thanks.
>
> -- Kevin
>
>
>
> Erik De Rijcke wrote:
>
>> Hi all,
>>
>> Any follow up on this? I'm experiencing the same issue here (latest
>> openjfx8 on wayland using mesa egl/gles2).
>>
>> Erik
>>
>> On Wed, Mar 2, 2016 at 6:36 PM, Chien Yang <chien.yang@oracle.com> wrote:
>>
>>
>>
>>> Hi Maurice,
>>>
>>> Can you please file a JIRA on this issue?
>>>
>>> Thanks,
>>> - Chien
>>>
>>>
>>> On 3/1/16, 11:45 PM, Maurice wrote:
>>>
>>>
>>>
>>>> Jim,
>>>>
>>>> A solution in line of that of Johan Vos [1] works. JavaFX can be run and
>>>> doesn't crash on startup when compiling the shaders. I think they
>>>> should be
>>>> taken into account for at least JavaFX 9, as it reduces a very serious
>>>> bug
>>>> to a possible optimization.
>>>>
>>>> Maurice.
>>>>
>>>> [1] https://bitbucket.org/javafxports/8u60-rt/commits/595633bbaa
>>>> e36f98d85d47d276294442ea43488c
>>>>
>>>> Op 02-03-16 om 02:22 schreef Jim Graham:
>>>>
>>>>
>>>>
>>>>> The thing about this use of pixcoord is that the same information can
>>>>> be
>>>>> supplied much more efficiently as a pair of texture coordinates.  The
>>>>> value
>>>>> of pixcoord ends up being a linear equation over the area of the
>>>>> primitive
>>>>> which is exactly what texture coordinate samples give you for free.
>>>>>
>>>>> I believe some of the other gradient methods use that texture
>>>>> coordinate
>>>>> technique to avoid having to use pixcoord, but the issue is that we've
>>>>> hard-coded all of our VertexBuffer streams to have exactly 2 sets of
>>>>> texture coordinates and so you only get room to pass in so many values
>>>>> and
>>>>> these (i.e. this family of) shaders are already using those texture
>>>>> coordinates to pass in too many values to leave enough free for the
>>>>> gradient fractions.
>>>>>
>>>>> This shader could be avoided, I believe, by rasterizing the shape into
>>>>> an alpha mask and using one of the alpha mask gradient shaders that
>>>>> doesn't
>>>>> rely on pixcoord.  In fact, in some embedded environments these shaders
>>>>> have so many computations per pixel that running the shape rasterizer
>>>>> on
>>>>> the CPU actually wins performance (and especially if you cache the
>>>>> alpha
>>>>> masks as some of our NGShape nodes do)...
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 3/1/16 9:10 AM, Maurice wrote:
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
[prev in list] [next in list] [prev in thread] [next in thread]