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:
