GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM)
Erik De Rijcke
derijcke.erik at gmail.com
Wed Sep 28 14:22:19 UTC 2016
Any follow up on this? I'm experiencing the same issue here (latest
openjfx8 on wayland using mesa egl/gles2).
On Wed, Mar 2, 2016 at 6:36 PM, Chien Yang <chien.yang at oracle.com> wrote:
> Hi Maurice,
> Can you please file a JIRA on this issue?
> - Chien
> On 3/1/16, 11:45 PM, Maurice wrote:
>> A solution in line of that of Johan Vos  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.
>>  https://bitbucket.org/javafxports/8u60-rt/commits/595633bbaa
>> 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:
More information about the openjfx-dev