Open sinisterchipmunk opened 12 years ago
Next release will take a much more proactive approach to issues like these. It'll query the limits of the graphics hardware and then reject shader portions which exceed its capabilities during preprocessing, without waiting for a compile, link or runtime error to occur.
Jax is not gracefully recovering when the max. number of shader arithmetic instruction slots has been reached. I'm seeing this in the error reports for the Jax demos page, but I'm not sure what hardware this error is occurring on, so if anyone has more information, please report it!
Jax should reject either the obvious no-go shader, or the last shader in the chain, and attempt to recover by using a more simplistic shader. It should handle a worst-case scenario with an error passed into ApplicationController or the current controller. I can't tell whether it's doing the latter, but the error indicates it's definitely not failing back to a more basic shader.
It's also a remote possibility that Jax is working properly, but the hardware in question isn't capable of running even the most basic shader, so it barfs. Not much we can do in this case though, because the basic Jax shader is well within the bounds of "minimum maximums" in the WebGL spec. If the drivers aren't up to spec, that's not our fault, though we should work around the issue if we can find a way to do so.
Example of the error encountered: