On 23 Nov 2009, at 16:54, Christopher Wright wrote: >> Have you experienced a performance hit doing it this way? I don't see the >> reason for your (or Christopher's, I see he just replied) aversion to it. > > > My personal aversion comes from the "check a flag" trick being polling (and > using an ivar), and polling being lousy when it's not necessary (ditto for > ivars). Whether or not the cost is "significant", if it's easy to avoid, I > figure it's worth it. Image Downloader in Async mode, and Rendering > Destination Dimensions are patches that don't execute every frame (not > polling) -- there's no reason to expect anything less from plugins. > > (Not trying to start a war or anything, just explaining my aversion/rationale > ;)
ha no no, not wishing to engage in warfare either, just I'm being slow to grasp the problem with idle execution in this context. In QC, it seems likely that the rendering environment will be doing idle-time processing of its own (housekeeping recycled resources, etc), and as long as our code can correctly identify situations in which it should do nothing at all in execute: atTime: withArguments: (which it should anyway, even with ...timeModeNone or ...timeBase) the overhead will be at worst a per-idle method invocation from the renderer's own idle-time handler plus a single comparison of a boolean value (so long as that value is modified in a thread-safe way) inside our execute: atTime: withArguments:. This tiny, miniscule cost to the user seems preferable to the cost to the developer of updating the software when a future system update breaks his reliance on undocumented methods. A broader discussion of the merits of runtime-loadable code modules which conform to a strictly defined API probably would be edging towards warfare ;) On 23 Nov 2009, at 16:51, Memo Akten wrote: > If the proper way is to keep it looping in idle and check the flag, then I > can do that, no problem. That's the only way the public interface provides. Cheers, T _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
