> Forgive the untechnical question (I'm no coder), but I always thought > the reason why QC didn't support send and receive pairs was because > there was some inherent performance problem when you break the > hierarchy and allow data to be sent willy nilly? > > For the record, I would love such a thing.
Since QC's pull-driven (consumers pull data through the graph), there's no "sending" -- a broadcaster with no receiver does very little work (sets a pointer somewhere that never gets read), which is as close to "free" as you can get without actually being free :) The more fundamental problem is execution order -- if a broadcaster is layer 2, and a consumer that uses it is layer 1, it will always operate on 1-frame stale data (which could be wrong, and isn't entirely obvious). A variation on it is types -- if you send a mesh, but the receiver expects a string, what happens? normal noodle conversions can only do so much, and some things are out-right forbidden; broadcasting pretty much prevents forbidden connections from being prevented. Introspection can "protect" you from exploding, but there's a small cost to doing that all the time. Lots of people want this, inside and outside :) _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
