Bug 124211 - Web Inspector: Canvas: support editing WebGL shaders
Summary: Web Inspector: Canvas: support editing WebGL shaders
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Devin Rousso
URL:
Keywords: InRadar
Depends on: 138593
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-12 09:57 PST by Timothy Hatcher
Modified: 2017-08-08 18:55 PDT (History)
17 users (show)

See Also:


Attachments
Patch (18.73 KB, patch)
2017-08-03 14:36 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff
Patch (20.55 KB, patch)
2017-08-04 15:26 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff
Patch (20.05 KB, patch)
2017-08-08 16:46 PDT, Devin Rousso
mattbaker: review+
Details | Formatted Diff | Diff
Patch (19.13 KB, patch)
2017-08-08 18:14 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Timothy Hatcher 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/
Comment 1 Radar WebKit Bug Importer 2013-11-12 09:57:28 PST
<rdar://problem/15448958>
Comment 2 Devin Rousso 2017-08-03 14:36:55 PDT
Created attachment 317156 [details]
Patch
Comment 3 Devin Rousso 2017-08-04 15:26:26 PDT
Created attachment 317301 [details]
Patch
Comment 4 Matt Baker 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.
Comment 5 Matt Baker 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.
Comment 6 Devin Rousso 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.
Comment 7 Devin Rousso 2017-08-08 16:46:46 PDT
Created attachment 317649 [details]
Patch
Comment 8 Matt Baker 2017-08-08 16:53:18 PDT
Comment on attachment 317649 [details]
Patch

r=me
Comment 9 Devin Rousso 2017-08-08 18:14:10 PDT
Created attachment 317662 [details]
Patch
Comment 10 WebKit Commit Bot 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>
Comment 11 WebKit Commit Bot 2017-08-08 18:55:58 PDT
All reviewed patches have been landed.  Closing bug.