On the quartzcomposer-dev list, someone mentioned that the ‘Render in Image’ patch is pretty gpu etc. intensive. I use it quite a lot for switching between different visible patches, so I thought I'd check it out in a bit more detail.

This zipped Quartz Composer file is a simple composition that uses ‘Render in Image’ and a ‘Multiplexer’ to switch between different patches.

This zipped Quartz Composer file is the same composition, but using 5 standard macro patches and a javascript patch, designed to work as an inverse multiplexer (taking a index and switching the relevant output to 1, with rest set to 0).

What was the outcome? Well the latter, uses 10 less patches, uses less AGP memory (measured using OpenGL Driver Monitor - in /Developer/Applications/Graphics Tools), and shows a smoother line in debug for Execution Time and Rendering Time. It definitely shows savings even on such a simple composition.

I find it odd that you have to use a javascript patch to do something so straightforward - surely this must confuse beginners? Also I couldn't find a way of making the javascript detect how many outputs there are. Finally, although the javascript patch is fine for this, it would be better to have a real patch that could take a default input and a selected input, and allow those inputs to be any type (image, number, index, etc).

Hope this helps someone eke a bit more speed out of their composition. SteamSHIFT out.

Technorati Tags:
VJ, quartz composer, mac, osx, experiments, macro, javascript