GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM)

[Kevin Rushforth]

Hi Erik,

Thank you for filing this. I see the bug has been filed as JI-9044144. 
Once the incident team finishes reviewing it they will transfer it to 
the JDK project where it will be publicly visible.

-- Kevin


Erik De Rijcke wrote:
> I filed a report but it seems to be under review(?).
>
> On Wed, Sep 28, 2016 at 6:06 PM, Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at 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 at oracle.com <mailto:chien.yang at 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
>                 <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:
>
>                            
>
>                      
>
>