The existing logic for texture level checking in WebGLRenderingContext::validateTexFuncLevel had an off-by-one error. It ensured that we never exceeded the value of "m_maxTextureLevel" (or "m_maxCubeMapTextureLevel"). However, these values mark the upper bound of the texture level; the storage is sized to hold this count of entries, but the actual levels are 0-indexed.
Created attachment 221078 [details] Patch
Committed r161907: <http://trac.webkit.org/changeset/161907>
fast/canvas/webgl/webgl-compressed-texture-size-limit.html fails on all Mountain Lion bots, and is flaky on Mavericks. Brent, are you available to look into this now?
Re-opened since this is blocked by bug 126963
Rolling out, bots are noisy tonight. Some diffs: http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK1%20(Tests)/r161909%20(12225)/fast/canvas/webgl/webgl-compressed-texture-size-limit-pretty-diff.html http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/r161931%20(1608)/fast/canvas/webgl/webgl-compressed-texture-size-limit-pretty-diff.html
(In reply to comment #3) > fast/canvas/webgl/webgl-compressed-texture-size-limit.html fails on all Mountain Lion bots, and is flaky on Mavericks. > > Brent, are you available to look into this now? Crap. It's graphics-card specific.
Revising tests to limit texture memory to 8196, to match our smallest test bots.
Committed r161978: <http://trac.webkit.org/changeset/161978>
This test is now crashing on bots (at least some, most haven't caught up yet): http://build.webkit.org/results/Apple%20Mavericks%20Release%20WK1%20(Tests)/r161978%20(2387)/fast/canvas/webgl/webgl-compressed-texture-size-limit-crash-log.txt
Re-opened since this is blocked by bug 126992
Committed r161996: <http://trac.webkit.org/changeset/161996>
<rdar://problem/15818236>