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.
the "problem" is largely philosophical -- polling is generally frowned upon, and in this situation there's no alternative (i.e. an incomplete/ insufficiently mature API). The actual performance implications are typically not severe (but also non-zero, which they could be were a "setNeedsExecution" api provided), which is why I see it as a "problem" (more of design than actual performance).
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:.
the per-invocation cost is indeed a bool compare + message send (not a lot -- measured in tens of nanoseconds probably). I can't think of any noteworthy overhead otherwise, other than the standard graph eval costs. A closer inspection of graph evaluation details would be necessary to point out any other costs to do-nothing executions vs. skipped executions.
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.
On the other hand, there are cases where users of undocumented APIs lead the way for sanctioned APIs in the future (see FSEvents, QCPlugIns in general, etc.) -- I'm confident Memo fully understands the implications of using undocumented methods (and in this case, if it had worked, it'd be 2 lines of code to change/maintain should things shift; not a significant time investment for him, though definitely frustrating for users in either case). I'm personally of the opinion that the official api, as currently drafted, is woefully incomplete and lacks several simple enhancements (not due to malicious intent or anything paranoid, but due to sheer lack of time/manpower on Apple's part, I suspect). As such, some prodding such as this could motivate/reprioritize apple's todo list.
A broader discussion of the merits of runtime-loadable code modules which conform to a strictly defined API probably would be edging towards warfare ;)
For this, I'd be firmly on the "it depends on the module's intent" camp -- if it's a one-off installation that doesn't need/expect to need to be supported, breaking rules isn't a big concern. If it's for a commercial/distributed product, following the rules is more prudent :) I'll leave it at that :)
As a side effect of this discussion, I noticed that the Image Downloader actually does execute every frame (lame), as do the MIDI input patches (which technically don't need to do anything if no midi sources are broadcasting/have changed state since the last frame). But only on 10.5 -- on 10.6 this changed to work as expected.
-- [ christopher wright ] [email protected] http://kineme.net/ _______________________________________________ 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]
