I don't find a bug relating to this, so it seems the bug was never filed.
Can you please file one?
Thanks.
-- Kevin
Erik De Rijcke wrote:
Hi all,
Any follow up on this? I'm experiencing the same issue here (latest
openjfx8 on wayland using mesa egl/gles2).
Erik
On Wed, Mar 2, 2016 at 6:36 PM, Chien Yang <chien.y...@oracle.com> wrote:
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/595633bbaa
e36f98d85d47d276294442ea43488c
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:
