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.


[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)...


On 3/1/16 9:10 AM, Maurice wrote:

Reply via email to