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