No graceful recovery when max shader instructions reached

[sinisterchipmunk]

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:

Error: Could not initialize shader!
Shader@0x051E2638(261,14): warning X3206: implicit truncation of vector type
Shader@0x051E2638(262,18): warning X3206: implicit truncation of vector type
Shader@0x051E2638(163,21): warning X3571: pow(f, e) will not work for negative f, use abs(f)
    or conditionally handle negative values if you expect them 
Shader@0x051E2638(242,14): error X5608: Compiled shader code uses too many arithmetic
    instruction slots (118). Max. allowed by the target (ps_2_0) is 64.
 (1,1): error X5609: Compiled shader code uses too many instruction slots (118). Max. allowed by the
    target (ps_2_0) is 96.

[sinisterchipmunk]

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.