WebGL texture problem

I have a very puzzling issue...

Since the 2d canvas is too slow to make whole screen realtime pixels shaders, I decided to create a plugin for that, which uses WebGL.

Searching across the web, there's only one lib doing that for the moment : glfx.js

<img src="http://i.imgur.com/pmKUv.png" border="0" />

I tried to integrate it inside a C2 plugin.

The idea is simple : retrieve an image from an <img> tag, pass it as a texture to a "webgl-experimental" <canvas>, applu shader on it, display back the <canvas>.

I manage to draw a Sprite on C2's canvas, extract it to write it in an <img> tag inside the index.html DOM (that tag is going to have "visibility:hidden" set in the future, when everything is bug-free).

glfx.js then load that <img> in his webglcanvas, and apply on it a sepia shader (to start with something).

I then retrieve the content of that <canva> via toDataURL() (in a base64 string), set that string as the .src for a new Image(), and draw that back inside C2's canvas (with ctx.drawImage()).

Here's the good news : it works perfectly in Firefox, as you can see on the top screenshot. But it fails badly in Chrome (same problem for Safari), so I suppose it's a Webkit-wide problem.

I went to #webgl, on freenode, and nobody heard about that problem.

I change the glfx.js source to set "preserveDrawingBuffer" at true.

I scoured the two buglists (chromium & webkit), there's nothing on it.

I didn't even find a demo on the web about that chain of event (namely img -> webglcanvas -> toDataURL - > drawImage(2dcanvas)).

So if somebody has an idea, or has already encountered that bug, don't hesitate !

FYI we're planning to add WebGL shaders integrated in to the editor in a future build.

What's the image's source? You might have stumbled in to a cross-domain security limitation.

Ashley: the image source is from the same domain (in the exported image folder). I don't think it's a CORS related problem, since it works with Firefox.

ARe you planning to add the possibility to load custom shaders, or the shaders are going to be prebuilt ?

We'll have custom shaders.

It might be a CORS bug since it's new, or if you're running on file:/// the file is probably blocked anyway. Not sure I'm afraid.

By the way, something I'm not sure : when you create dynamically a new Image () (var imgTmp = new Image()), and you want the onload() function to fire, do you have something specific to do (apart from this.runtime.redraw = true) ? (because it doesn't fire under Chrome).

Do any of the articles help?

link 1

link2

link3

If not, just ignore me.

<img src="smileys/smiley17.gif" border="0" align="middle">

chrisbrobs : the article aren't related directly to the problem (since I up everything to the Public folder of my Dropbox account, I'm always sure it's not a cross-domain issue). But the links are interesting. I stumbled upon a active Blob demo which was impressive ! ;)

Pode: Do you have reached/found a working implementation of "toDataURL" - for Chrome(WebGL). I don't know if mine ("acts.Request") is wrong or it's a bug of chrome webGL. I have tried a lot of different ways but however I always get empty images with chrome. In Firefox WebGL works without problems.

For me it seems that the online-demo you've posted at the [Behavior] Extract Sprite to base64 string has the same problem when I extract the base64 with Chrome WebGL

Joe7 : in the "Your Creations" subforum, I posted a demo of a future plugin with WebGL effects (the exact one from which the screenshot is posted in this topic).

I managed to extract the webgl texture as an image, and to inject it in the Sprite.

I won't be able to look your code this week-end, but I can check that next week if you want.

Pode: Sounds very good.

There is one thing I do not understand. When I look at the demo of the "Extract Sprite" behavior the extracted base64-string with chrome and webgl seems to be wrong. But - when I use the behavior in my plugin-demo the sprite extract with your plugin is the only thing that works on chrome with webGL. I suppose that the blank-images bug has a painting origin.

I've built a similar behavior like yours for extracting the base64 of the C2-cangs. It works perfect on FF.. very great but it also fails on Chrome - useless.

Pode: I think I've fixed this problem now and can look at the next ones.. Thanks for your helpfulness. Your future plugin looks awesome.. <img src="smileys/smiley2.gif" border="0" align="middle" />