You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a quick look into the source I figured the solution of hooking into the methods of the WebGLRenderingContext prototype might not work for contexts created in foreign execution contexts, namely inside an iframe and exported to the main JS context. One possible workaround I can think of is to check the DOM for canvas elements and then set up a mutation observer to check for canvas elements added to the main DOM. That won't work for a canvas inside an iframe and offscreen rendering contexts though.
But calling getContext on a canvas of a foreign exceution context should always give you the proper foreign rendering context as far as I know.
As a hook into the program info I suggest useProgram in any case, because that would catch already compiled programs without refreshig the page and is usually called during rendering.To query the attached shaders you could use gl.getProgramParameter( programRef, gl.ATTACHED_SHADERS ) to get the shader references and then gl.getShaderSource( shaderRef ) and all other relevant states.
In case of simple scenes with only one program you can get that in any case by querying gl.getParameter( gl.CURRENT_PROGRAM ) first. So you would ge those already linked and used before you could reach them.
If the canvas doesn't leave the iframe or prevents writes on the prototpe nothing really helps, but that'd still make your implementation a bit more robust for most cases. Hope it helps.
The text was updated successfully, but these errors were encountered:
That was my guideline, too. About everything that doesn't work in the Firefox editor doesn't work with the extension.
The mutation observer solution seems fine, but sometimes the WebGLRenderingContext is not necessarily attached to the DOM. There's several use cases with ad-hoc rendering contexts being created (the extension itself does it).
Tracking the current program is a solution worth considering, but as an improvement of the current method. I'm thinking that to enable shader highlighting the extension needs to track all fragment shader sources, in order to have two versions: the normal one and the highlighted one.
I'm stuck on an airport, I'll follow up on this issue when I'm back!
With #1 fixed, only needs to be reloaded if the Editor is opened after the target page is loaded. Could be improved by automatically instrumenting regardless, but might be assuming too much. Now it works like Firefox's
After a quick look into the source I figured the solution of hooking into the methods of the WebGLRenderingContext prototype might not work for contexts created in foreign execution contexts, namely inside an iframe and exported to the main JS context. One possible workaround I can think of is to check the DOM for canvas elements and then set up a mutation observer to check for canvas elements added to the main DOM. That won't work for a canvas inside an iframe and offscreen rendering contexts though.
But calling getContext on a canvas of a foreign exceution context should always give you the proper foreign rendering context as far as I know.
As a hook into the program info I suggest useProgram in any case, because that would catch already compiled programs without refreshig the page and is usually called during rendering.To query the attached shaders you could use
gl.getProgramParameter( programRef, gl.ATTACHED_SHADERS )
to get the shader references and thengl.getShaderSource( shaderRef )
and all other relevant states.In case of simple scenes with only one program you can get that in any case by querying
gl.getParameter( gl.CURRENT_PROGRAM )
first. So you would ge those already linked and used before you could reach them.If the canvas doesn't leave the iframe or prevents writes on the prototpe nothing really helps, but that'd still make your implementation a bit more robust for most cases. Hope it helps.
The text was updated successfully, but these errors were encountered: