Multiple Canvas Targets

[positlabs]

Can we allow one instance of Seriously to render to multiple targets? Currently only the first call to seriously.target() is successful.

var t1 = seriously.target('#t1'); // renders
var t2 = seriously.target('#t2'); // does not render

A workaround is to create another instance of Seriously and point it to the second target.

var s2 = new Seriously();
var t2 = s2.target('#t2');

If Seriously instances only accept one render target, should it be an argument required for instantiation?

var s = new Seriously('#render-target')

If we remove the option of creating a target with the .target() method, it would prevent devs from mistakenly trying to create multiple targets.

Another option would be to throw an error when the dev attempts to create a second target.

[brianchirls]

Yeah, this is something I've been punting on for a while. The original idea was that a second canvas would get its own WebGL context and that rendering to it would involve reading the input node's texture to a pixel array and then drawing that to the other context. But that can be very slow, especially if the input node is any bigger than a thumbnail.

There is a proposal for sharing resources between two or more WebGL contexts, which would allow multiple target nodes to work somewhat seamlessly (in theory, at least). So that's on my to-do list as soon as browsers start supporting it.

(After the work I did on #14, it should be possible to destroy a target node and then create a new one with a different canvas. Seriously will be able to use the new context and create all new resources for every node in the composition. This is a good first step in that direction.)

There is at least one legitimate way to have multiple targets now, which is if a target node is attached to an existing WebGL texture. That should work if you want to use Seriously as a post-processing module for an existing game engine or something like Three.js.

So I think probably the right move is to throw an error when a second target is created until shared resources is supported. Maybe I can allow an option to force rendering to a second canvas via readPixels if the author really wants to do that.

What do you think?

[positlabs]

I like that plan. It would actually be really useful to have that ability for the node graph editor. It would only need to be thumbnails in that case, anyway - just something to show a preview of what effect the node is having on the input/s.

[brianchirls]

Yeah, the thumbnail case is exactly what I envisioned for this as well.

Okay, I should be able to get this working pretty soon. But it could take some iteration to work out the kinks. It's important to note that Chrome and Firefox will start to destroy WebGL contexts once you make more than 16 of them. Don't know what IE does.

[brianchirls]

Could use a little more feedback here, if you have a second...

I'm thinking that rather than throw an error, the bad node will still be created but in an error state. You'll be able to query that state, and an "error" event will be triggered with the error message. That way it won't interrupt the process of setting up the composition network, and the node state will still be queryable.

So, for example, in the future one device/browser may support multiple canvas nodes while another does not (same goes for a given source or effect type). If the node fails to load, you might still want to see it in your graphical editor, but it will just fail to render, rather than blow up in your face.

There could also be an option on the Seriously instance to throw an error.

What do you think?

[brianchirls]

I renamed this ticket from "Multiple render targets" because that can refer to something else and can be confusing.

[positlabs]

I like the graceful degradation approach, but it still requires the dev to know to inspect the node state (something they will hopefully do in the process of debugging). It's better than nothing, though - especially if multiple canvas targets will be a working feature in the future.

Anyway, it might be an edge case. Maybe it's just best to caveat in the docs somewhere.

[positlabs]

What about a warning via console.warn?

[brianchirls]

Right now, it's throwing an error. I think I'm gonna punt on the error state stuff for now because a) I don't want this to hold up the next release (maybe tomorrow?) and b) I'd like to hear some feedback based on real-world experience before determining the best way to move forward.

So I'm gonna close this for now. Please comment here if you have any objection or other related issues, and we'll re-open if necessary.