Quoting IOhannes m zmoelnig zmoelnig@iem.at:
the problem that i see is, that you would have a rendering-engine (the current GemMan) for each window. one of the problems arising here, is that auto-updating objects (like pix_film or particles) will have serious problems to stay "in time". the current solution in the multiple_window branch is to control the frame-rate centrally (this is: each window renders at the same rate, which might be a problem) and the use of display-lists sharing, which calls the render-object of each [object] exactly once per rendering cycle (but of course, display-list sharing might not really work everywhere).
the idea is, to use pd's messaging system for controlling. imagine a patch with 3 [gemwindow] objects, 2 of which are connected to the sole [gemcontrol]. you create 3 windows by sending a "create"-message to the [gemwindow]s and turn rendering on by sending "1" to [gemcontrol]. 2 of the windows will render the scene, the 3rd (which is not connected) will stay blank.
This explanation makes more sense to me. I haven't gotten the code yet, but the idea of having render targets independent of individual windows is great.
What about having render targets that are not displayed directly to a window like a render to texture or pbuffer? Those possibilities should be included with the reworking of the window and control elements. Does [gemrender] make sense as a way to render to a non-window target?
Also, are their any opportunities to take display lists further? Like build a chain that is a display list and then calling the list in another chain?
Finally, the render control could use some work. We should probably take a look at where time is being spent managing the chains and if timing could have a finer resolution and more stable frequency. Oh and if we could work out some sort of thread and priority solution to keep the damn GUI from stopping rendering then that would be top.
and thanks for being not grumpy ;-)
You caught me on vacation! ;)
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.