Modify the webgl line feature shaders. #816
Conversation
manthey
force-pushed
the
image-test-stability
branch
from
501d4ff to
ccf954d
Compare
|
Curiously, atan has issues both on Google's swiftshader and on osmesa (Mesa 17.2.8). This changes works around the problem on both of them. |
Chrome 65 and 66 when running in xvfb with openmesa do not compute atan(0, <negative>) correctly. Also, there are occasional int() casts that round down even when they are small integers. These changes make image comparisons more robust by working around the atan issue (this may be the issue detailed in chromium.googlesource.com/angle/angle/commit/da9fb09). I have submitted a new issue to chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=841296 to track this problem. With this commit, the baselines were regenerated with Chrome 64, and the test strictness requirements changed in PR #792 have been reverted. There are subtly differences between Chrome 64 and 66 (font aliasing is slightly different, and I think the other changes are because the shader float precision is subtly different, though I'm not sure of that).
manthey
force-pushed
the
image-test-stability
branch
from
ccf954d to
682fa56
Compare
| @@ -275,8 +286,8 @@ var gl_lineFeature = function (arg) { | |||
| ' vec4 color = strokeColorVar;', | |||
| allowDebug ? ' bool debug = bool(mod(fixedFlags, 2.0));' : '', | |||
| ' float opacity = 1.0;', | |||
| ' int nearMode = int(info.x);', | |||
| ' int farMode = int(info.y);', | |||
| ' int nearMode = int(floor(info.x + 0.5));', | |||
There was a problem hiding this comment.
is it because info.x is slightly less?
There was a problem hiding this comment.
We really want to use a round function, but WebGL doesn't have one. In the osmesa implementation, this is sometimes very slightly less than the integer we start with (2.999999 versus 3), so a very tiny addition would be sufficient, but a general round function is often floor(value + 0.5), so I've used that.
There was a problem hiding this comment.
Although the vertex shader produces consistent values (info.x at the three vertices will have an identical integer value in the range of [0-7]), this somehow is not always an exact integer in the fragment shader. I don't know what osmesa does that causes this (the various actual GPUs that execute this seem to always have the exact integer), but this works around the issue.
|
one thing i noted " shader float precision is subtly different" can you elaborate? We could ask for particular precision in the shader code. |
|
You can ask for three precisions - |
Chrome 65 and 66 when running in xvfb with openmesa do not compute
atan(0, <negative>)correctly. Also, there are occasional int() casts that round down even when they are small integers. These changes make image comparisons more robust by working around the atan issue (this may be the issue detailed in https://chromium.googlesource.com/angle/angle/commit/da9fb09). I have submitted a new issue to chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=841296 to track this problem.With this commit, the baselines were regenerated with Chrome 64, and the test strictness requirements changed in PR #792 have been reverted. There are subtly differences between Chrome 64 and 66 (font aliasing is slightly different, and I think the other changes are because the shader float precision is subtly different, though I'm not sure of that).