I understand the difficulty. I'm still facing many like it in my own plug-in
app (which I think I've mentioned before).
In this case, I'm building the clock display seen here:
http://www.spacevidcast.com/live/
For the next couple of days, you'll see two clocks at the bottom. My .qtz (and
a couple custom patches) render the black bar at the bottom, the gray/white bar
with blue logo, the green/white bars with clocks, and a blue/white bar that
will cover the right-borrom half of the screen when the count reaches T-1
minute (it shows six rapidly-changing ascent parameters).
Each of those sections is a macro in my composition. I use the anchor and image
dimensions patches to stack them left-to-right, anchored on the bottom-left
corner. What makes it difficult is that each one needs the previous ones'
widths, and that width is really only known within the macro (it loads the
image). I wish there were a way to get that width out for use by the other
macros, or the parent, in laying them out.
Perhaps there's another way to accomplish this type of layout that I haven't
thought of.
--
Rick
On Feb 21, 2011, at 08:59:11, Christopher Wright wrote:
>> Wouldn't that just lead to that macro being one frame behind?
>
> It's undefined. It could be 1 frame behind (as in, a consumer won't actually
> execute upstream consumers?), it could render out of order (as I outlined
> previously), or it could even double-render (layer 1 executes, layer 2
> executes, which requires layer 1 to execute again? this case is admittedly a
> bit contrived, but you can hopefully see how it could plausibly happen). The
> current implementation does what I said (out of order) iirc, but it's
> forbidden anyway so you can't actually see for sure (This was possible in
> Tiger, but never since, so things may have changed enough to change what it'd
> do if it were allowed).
>
> It's difficult to know which is "best" -- I'd favor macros not logically
> changing the graph, but that has other pitfalls. Maybe just enforced layer
> ordering would be possible (as in, upstream consumers _must_ have layer
> orders lower than downstream consumers). This would give a weird interface
> though (to a new user, it'd sometimes work and sometimes not, leading to more
> discussions like this, which crop up from time to time anyway ;)
>
> --
> 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/rmann%40latencyzero.com
>
> This email sent to rm...@latencyzero.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
