Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with foreign JS execution context and avoiding page reload #9

Open
Winchestro opened this issue Apr 9, 2015 · 3 comments

Comments

@Winchestro
Copy link

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.

@makc
Copy link

makc commented Apr 9, 2015

AFAIR firefox shader editor does not work for iframes either?

@spite
Copy link
Owner

spite commented Apr 10, 2015

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!

@spite
Copy link
Owner

spite commented Jun 9, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants