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

[Chien Yang]

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/595633bbaae36f98d85d47d276294442ea43488c
>
> 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:
>