|
|
Syphon+QuartzBuilder Problem Hi everyone, first of all thanks for all the help i already got from reading through this forum. I really learned a lot. i was working on a little projection mapping tool with syphon integration (cause i can´t afford Madmapper :) and i stumbled upon an odd thing. i´m running two quartz compositions ( a server comp with a syphon server plugin and a client comp with a syphon client plugin , the gpu load is around 60% both framerates around 20- 30fps- cool for me.. Now when i compile the client comp into an app with quartz builder and and then feed it with the same server composition via syphon,my GPU goes bananas and the framerate drops to 5-10 fps in the server comp..!?! the built app shows framerate of around 20 or so. I attached sample compositions and the built app.(the app renders on a second display and you may need to set the file path of the movie importer to a video on your disk) any thoughts would be appreciated :) |
the files didn´t get published so here they are..
Is your second display attached to a different graphics card? If so, the system has to copy the texture between cards which will definitely slow things down.
I´m running a Macbook with an Nvidia GeForce 320m. Both displays are connected to that graphics card. I allready tried the 32 bit modes of qc and the app.-doesn´t help.. The strange thing is that the problem only occurs when using the compiled Client App. The client composition works fine.
Are your windows overlapping? This quote from Franz may go some way to explaining the problem: http://kineme.net/forum/DevelopingCompositions/VideoMapping "QC rendering on main screen -> syphon, syphon -> MadMapper, MadMapper fullscreen on 2nd screen, in some complicated cases (such as one window over the other, and that kind of annoying BS) Apple engineer's quote: "This is due to WindowServer scheduling issue combined with having multiple displays being updated at the same time, combined with the way in which screen updates are done today on Mac OS X."
When I have encountered a slowdown hiding the server app usually increases the framerate.
I haven't done testing on this, but after looking at the composition, I think that you might try "not" setting up the server so that the output of the movie importer patch directly feeds the syphon input. I'd try setting it up so that the Syphon server is grabbing the openGL Scene and see if the performance improves.
If, for some reason you can't grab the openGL Scene, I'd try rendering the movie to a billboard inside of a Render In Image patch (with clear at layer 1), set at the pixel w/h you need, and then feed that to the Syphon input. I feel horrible suggesting that, and if it works, it's a somewhat inefficient workaround.
Failing all of that, I'd also try a/b-ing some other movie playing patch directly into Syphon the way you're doing it now, then also the OpenGL Scene grab route. I'm not trying to put you through the wringer, but looking through those routes might wind up resolving it, or at least giving you something workable.
Allright, thanks so far. I tried i tried all suggested setups, but no luck so far. the hint about hiding the server app window worked for me (though only with animation stuff when grabbing the openGL scene). Videos simply wont work, even when resized to a minimum and using vades movie importer rendering on a billboard. I get hoorrible dropouts and sometimes less than a frame per second.. (when using a compiled app) when using quartz composer as a server, not being able to hide the qtz composer viewer again leads to the problem scratchpole mentioned.. so no luck for me..
my initial goal behind this was to create a series of apps with syphon out( animation app, video playing app), and then pulling their syphon sources from the mapping app, so the different quads could have different image inputs. but i guess i´ll have to go back to doing everything in one big ass composition.
how do you guys set everything up for best performance? is there anything i could be missing?
You have no control over the apps you are building. (i.e., pixel format choices for OpenGL context, etc), so there may be masking of screens, or of renderers that could be causing an issue.