video out a javascript

there's several recent posts on multiple windows for opengl that you should do a quick search for.

with one graphics card that has two ports, it's not really an issue. you just drag your window where you want it. depending on what you're trying to achieve, @shared_context might be the way to go. search for andrew benson's "preview" jitter recipe for more info.

with two graphics cards, the short answer is to make sure your jit.windows are instantiated on the correct graphics card before you begin rendering (before you turn your qmetro on). otherwise, you may experience a dramatic drop in frame rate. the wat to do this is provide @rect attribute which are the coordinates of your additional monitors. jit.displays can help with this.

actually, why don't i just quote anton's definitive response from another mailing list:Quote:GL to multiple displays with multiple GPUs can be TRICKY. The issue is you have 2 GPUs, and whenever you move data from GPU a to GPU b, things will *slow down* big time (it reads data back to the main memory then re-uploads it). This also means you should NOT share texture resources across multiple GPUs (using @shared_context etc, as data GPU b needs resides in GPU as vram, and depending on how the OS X driver works it may not be smart enough to know to automatically mirror data in both).

I would make 100% doubly sure that you:

Make 2 completely distinct GL contexts.

Upload your data twice, to each context separately.

Space one window across both monitors on the same GPU (which you cant do if you have GPU a on monitor 1 and 4 (how will it span across?) , fix your display preferences and re-order your monitors physically)

And most importantly you will have to be very careful how you init your jit.gl.renderers -> windows:

If your patch starts up with all windows on a single monitor, turns on rendering, and then moves the windows to their proper location, you've effectively initted resources on GPU a, and moving things to GPU b after rendering is enabled DOES NOT MOVE THE RENDER CONTEXT, TEXTURES OR RESOURCES to GPU b. Thus doing that slow ass readback I mentioned.

You can work around this for context a make a named matrix jit.matrix temp_a 4 char 320 240

Send draw_to temp_a, to jit.gl.renderer. This will force the renderer to switch drawing to your context, and THEN to your window, which is now in the right location, and force it to move things onto the proper GPU. Now do the same thing for b.

This stuff is very subtle and somewhat annoying if the conceptual peices as to how GL works are not understood, because the ramifications of ordering things unintentionally the 'wrong' way can have serious performance implications.