RESOLVED FIXED Bug 124211
Web Inspector: Canvas: support editing WebGL shaders
https://bugs.webkit.org/show_bug.cgi?id=124211
Summary Web Inspector: Canvas: support editing WebGL shaders
Timothy Hatcher
Reported 2013-11-12 09:57:11 PST
For WebGL support we are likely going to show the shaders in the Resources sidebar. We should make them editable too. See: https://hacks.mozilla.org/2013/11/live-editing-webgl-shaders-with-firefox-developer-tools/
Attachments
Patch (18.73 KB, patch)
2017-08-03 14:36 PDT, Devin Rousso
no flags
Patch (20.55 KB, patch)
2017-08-04 15:26 PDT, Devin Rousso
no flags
Patch (20.05 KB, patch)
2017-08-08 16:46 PDT, Devin Rousso
mattbaker: review+
Patch (19.13 KB, patch)
2017-08-08 18:14 PDT, Devin Rousso
no flags
Radar WebKit Bug Importer
Comment 1 2013-11-12 09:57:28 PST
Devin Rousso
Comment 2 2017-08-03 14:36:55 PDT
Devin Rousso
Comment 3 2017-08-04 15:26:26 PDT
Matt Baker
Comment 4 2017-08-08 14:38:28 PDT
Comment on attachment 317301 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=317301&action=review > LayoutTests/inspector/canvas/updateShader.html:31 > + description: "Tests updating a program's vertex shader.", Nit: "Tests updating a program's vertex shader source." > LayoutTests/inspector/canvas/updateShader.html:45 > +`; Style: the trailing "`;" should start in the same column as "const source =`". > LayoutTests/inspector/canvas/updateShader.html:53 > + suite.addTestCase({ These two test cases could share code, parameterized on shaderType. > LayoutTests/inspector/canvas/updateShader.html:152 > + suite.runTestCasesAndFinish(); It would be ideal if the tests could be written against the model/controller layer, instead of the protocol. Using ShaderProgram's update shader methods would exercise both the frontend and protocol. I can see why this might have been necessary, since ShaderProgram doesn't retain errors returned from CanvasAgent or expose them to the outside. It might be worth looking into making a change to ShaderProgram, and adding an optional callback to the shader update methods to be notified of success/failure info. What do you think? > Source/WebCore/inspector/InspectorCanvasAgent.cpp:314 > + errorString = contextWebGL->getShaderInfoLog(shader); Does it matter that we now have two paths for sending shader/linker errors to the frontend? Do they send identical data? Eventually we'll want to show errors inline, in the shader's TextEditor. Where would the error data be taken from to do this? The Console? The Canvas protocol? > Source/WebInspectorUI/ChangeLog:7 > + Reviewed by NOBODY (OOPS!). This patch is introducing new UI, which warrants a brief summary. > Source/WebInspectorUI/UserInterface/Models/ShaderProgram.js:87 > + console.assert(!error, error); Shouldn't we do something with errors, or lack there of? The program could track the result of the last operation, and invalidate it once another update is performed. Currently one has to toggle between the Console and Resources tab to see if the edits succeeded.
Matt Baker
Comment 5 2017-08-08 14:45:12 PDT
Do you have a test for two shaders which both compile, but cannot be linked? An example of this is mismatched varying variables.
Devin Rousso
Comment 6 2017-08-08 16:19:25 PDT
Comment on attachment 317301 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=317301&action=review >> LayoutTests/inspector/canvas/updateShader.html:45 >> +`; > > Style: the trailing "`;" should start in the same column as "const source =`". If I indented the "`;" then there would be a lot of trailing whitespace other than just "\n" at the end of the source. I would prefer to keep it where it is. >> LayoutTests/inspector/canvas/updateShader.html:152 >> + suite.runTestCasesAndFinish(); > > It would be ideal if the tests could be written against the model/controller layer, instead of the protocol. Using ShaderProgram's update shader methods would exercise both the frontend and protocol. I can see why this might have been necessary, since ShaderProgram doesn't retain errors returned from CanvasAgent or expose them to the outside. > > It might be worth looking into making a change to ShaderProgram, and adding an optional callback to the shader update methods to be notified of success/failure info. What do you think? I'm not sure I like the idea of adding an optional since it won't be used in any case other than tests. We follow this pattern of testing directly on the protocol in many other tests. >> Source/WebCore/inspector/InspectorCanvasAgent.cpp:314 >> + errorString = contextWebGL->getShaderInfoLog(shader); > > Does it matter that we now have two paths for sending shader/linker errors to the frontend? Do they send identical data? Eventually we'll want to show errors inline, in the shader's TextEditor. Where would the error data be taken from to do this? The Console? The Canvas protocol? I will just use the console to send errors. Linking the error line/column to the TextEditor will come in a later patch. >> Source/WebInspectorUI/ChangeLog:7 >> + Reviewed by NOBODY (OOPS!). > > This patch is introducing new UI, which warrants a brief summary. This patch doesn't actually introduce any new UI. It just makes the existing shader TextEditors editable. Also, I think the title is pretty self-explanatory. >> Source/WebInspectorUI/UserInterface/Models/ShaderProgram.js:87 >> + console.assert(!error, error); > > Shouldn't we do something with errors, or lack there of? The program could track the result of the last operation, and invalidate it once another update is performed. Currently one has to toggle between the Console and Resources tab to see if the edits succeeded. I will be adding inline errors in a later patch.
Devin Rousso
Comment 7 2017-08-08 16:46:46 PDT
Matt Baker
Comment 8 2017-08-08 16:53:18 PDT
Comment on attachment 317649 [details] Patch r=me
Devin Rousso
Comment 9 2017-08-08 18:14:10 PDT
WebKit Commit Bot
Comment 10 2017-08-08 18:55:57 PDT
Comment on attachment 317662 [details] Patch Clearing flags on attachment: 317662 Committed r220436: <http://trac.webkit.org/changeset/220436>
WebKit Commit Bot
Comment 11 2017-08-08 18:55:58 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.