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

Maurice info at cuhka.com
Wed Mar 2 07:45:03 UTC 2016


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:



More information about the openjfx-dev mailing list