workaround_old_chromium_webgl_bug #7459
Conversation
| self.btest('webgl_draw_triangle.c', '0', args=['-lGL', '-s', 'OFFSCREEN_FRAMEBUFFER=1', '-DEXPLICIT_SWAP=1']) | ||
|
|
||
| # Tests that -s WORKAROUND_OLD_WEBGL_UNIFORM_UPLOAD_IGNORED_OFFSET_BUG=1 rendering works. | ||
| @requires_graphics_hardware |
There was a problem hiding this comment.
Does this actually test that code path - does it force the polyfill on somehow?
There was a problem hiding this comment.
It just tests that code compiles with that flag enabled. I don't think it is worth spending time to maintaining a test infrastructure where we would enforce the path to kick in.
| } | ||
| } else { | ||
| view = {{{ makeHEAPView('F32', 'value', 'value+count*4') }}}; | ||
| #if WORKAROUND_OLD_WEBGL_UNIFORM_UPLOAD_IGNORED_OFFSET_BUG |
There was a problem hiding this comment.
is this needed for every single F32 heap view?
How about creating a helper function to avoid all the code duplication, makeGLHEAPView (adding "GL" in the name, and it adds this check)?
There was a problem hiding this comment.
No, it is needed only specifically for these views that it was added to. I would not want to craft any abstractions for this. If I added a makeGLHEAPView() (which lives in core src/parseTools.js) that we'd have to maintain just for this case, then someone would wonder why only parts of src/library_gl.js used makeGLHEAPView() and others used regular makeHEAPView() and it might leak to being used everywhere. I'd prefer to do this as KISS as possible, not building any complexity on top of this.
juj
force-pushed
the
workaround_old_chromium_webgl_bug
branch
from
bd06255 to
b140131
Compare
juj
force-pushed
the
workaround_old_chromium_webgl_bug
branch
from
b140131 to
0e91891
Compare
|
Its been 5 years since this landed. I wonder if we can remove this workaround now? |
|
Speculative PR: #20925 |
3 participants
Add -s WORKAROUND_OLD_WEBGL_UNIFORM_UPLOAD_IGNORED_OFFSET_BUG=1 option.