> Layers are always rendered sequentially to completion starting from > the consumer backwards‚ all of layer 1, then all of layer 2, then all > of layer 3 etc. (this goes for sublayers, etc)
Correct (for renderers/consumers -- processing patches are not executed in any defined order) > So if a Receiver exists in Layer 1, and the corresponding Sender > exists in Layer 2, then the output of this receiver will be > potentially unexpected. Not quite -- the output of the receiver is "well-defined" in a weird sense: on the first frame, the output is "undefined" (nothing has set it yet), probably a default like 0. On subsequent frames, it's either the previous frame value (if a sample-and-hold method is employed), or still undefined (if the values only persist for a single frame). Where this gets more confusing is when we take the above (processing patch execution order is not strictly defined), and combine it with our receiver (which cannot be a consumer, since it has outputs) -- now we cannot reliably control whether the sender executes before or after the receiver (which is a consumer). For a quick stroll through history, on 10.5 a consumer on layer 1 would execute all upstream patches, then execute itself, then layer 2 would follow suit (skipping already-executed upstream patches). On 10.6, _all_ upstream patches are executed before _any_ consumers are executed (As part of the idle-state detection feature on Snow Leopard); because processor order is never defined, this is "ok", but that means it's impossible to make future-proof compositions (unless processing patch order is also well-defined, which piles on a new set of problems). [Note: all that mess is an implementation detail you generally shouldn't need to know or care about -- don't ever depend on it] > Because layer order cannot be changed by the composition, the > Receiver will always know if it's at risk of being out of sync? > If Rendering mode was set to bug-finding, could the entire patch be > run twice, and differences in Send/Receive states be highlighted? Because of the undefined-ness of non-consumer patch execution order, debug mode cannot possibly provide meaningful data on this -- it could be totally valid on one version, and completely wrong on another, and there's no way it can know. -- Christopher Wright christopher_wri...@apple.com _______________________________________________ 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
