Threading / quartz composition performance

psonice's picture

Just wondering what methods there are of getting quartz performance up. At times my demo seems to be CPU limited, so apart from the obvious optimising within the composition, what can be done to improve it?

I've tried enabling multi-threaded opengl, that seems to improve performance but only slightly, and there is still one thread using 100% of one core.

Is there any sane way of enabling threading for the rest of quartz? Or any other way of increasing performance either within QC or from an application?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cwright's picture

First, disable multithreaded opengl; it's not what you think, and never helps performance (and adversely harms performance in special cases like Render In Image, GLTools, and Kineme3D)

The graph evaluation model used internally is very much single threaded; It would be possible to evaluate distinct graph pieces in parallel, but that's some tricky code, and I'm not surprised that Apple haven't done that yet; many patches simply aren't CPU-limited, but GPU limited (GLSL shaders and Core Image filters being notoriously expensive). I've done some experiments in threading parts of it via hacks (mostly for audio), and it always ends in disaster due to complexity (with the source code, it would be much easier, but from a plugin's point of view it's very difficult).

Disabling patches that aren't producing output can reduce the amount of work that QC needs to do each frame. Limiting the use of Iterators, the use of Javascript, and very deep macros will help a bit when possible (macros aren't very expensive at all; maybe 3 extra messages per frame, so removing that should be an absolute last step -- it's mostly an act of desperation as far as I'm concerned, but it's an optimization nonetheless).

Disabling VBLSync seems to help performance on my machine, at the cost of shearing/tearing. Enabling hardware everything (software gl and software core image will destroy performance) helps, but that's the default configuration anyway.

If all else fails, plop down some feature requests for tuned plugins -- it's difficult to beat the performance of compiled code :)

psonice's picture
Nothing I've not already

Nothing I've not already done then really (except the flattening macros thing, and I reckon 2,500 patches with no macros might be slightly annoying ;) I'll disable multithreaded gl then.. it was making marginal difference at best anyway. I think I'd used it where there was no render in image or similar, so perhaps it wasn't changing anything at all.

Actually, I have noticed that there's a few common functions that take a few patches but would be easily done with one. I think some would be very easy to do as plugins too. I'll add a few here, and if others think they would be useful (and i've not missed a better way of doing them with QC) I'll add them to the request list:

  1. a 'looped timelines' patch. It's really handy to have looping animation, and it's necessary to have the timelines, patch time, and a range patch to do it. (Actually I do remember seeing a way to loop it, but I can't find it now, so maybe that was another app?) That would just be a standard timelines patch, but with a "loop time" input of some sort.

  2. a 'pattern editor'. This would be similar to the timelines patch, but would be limited to a short sequence of 1s and 0s, which would run in a loop. That would be much more efficient than the timelines patch for enabling/disabling patches/effects I think.. although maybe the timelines patch is efficient enough?

tobyspark's picture
keep those simple plug-in ideas coming thats exactly what i'm working on for my own uses. whenever i find myself needing a bit of javascript for example, i'm trying to write an obj-c patch instead

non-image processing plug-ins tend to be fairly easy to write, i've only done a few but i have another potential qc project on the horizon...


cwright's picture
sort-of loop time?

I guess you might be able to use an LFO (my personal favorite function generator patch) to drive the patch time of a timeline... sawtooth up would loop, while triangle would mirror-loop. It's not an all-in-one solution, but it's 1 patch less than patchtime + range + timeline...

psonice's picture
LFO loop time

LFO could also work, although you'd have to check that it 'keeps time' well enough and starts at the right point. I guess (without checking) that neither would be an issue.

The reason I went with the range method though is that I'm using my own timers that match the music BPM rather than seconds, so to keep the loop in synch I use that as an external time source. Then it's just a choice between LFO and range, and I think range will be much more efficient.

I'll make a note here of any other little bits that would benefit from a single patch then :) I've almost cut javascript out, but I think there's probably a few macros I've used that are handy and could be made into patches. I'm going through the demo now and cleaning + documenting things, expect the first part pretty soon :)

toneburst's picture
Patch Time Is Cool

All those patches with hidden Patch Time inputs are cool. Interpolators are especially good when driven by an LFO, or even a straight control splitter. I find them invaluable for modifying control curves. You can even use them to reverse the action of a particular control, so it goes from, say, 1 up to 0, or between 2 other arbitrary values, with different curves. They work really well for distributing values inside an Iterator too, with the Patch Time linked to the Iteration Index.


Quartz Composer Blog:

Music Site: