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:
