I filed a report but it seems to be under review(?). On Wed, Sep 28, 2016 at 6:06 PM, Kevin Rushforth <kevin.rushfo...@oracle.com > wrote:
> 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: >>>>> >>>>> >>>>> >>>> >>>> >>>
