Is the layout dynamic? If not you can just hard code the widths. I did something simliar where I put the a billboard inside of a render in image patch. You can then set an output of the total width, which I then fed back through to the same render in image patch. It screwed up a bit when changing size on the fly, but worked pretty well when the composition loaded.
Hopefully that might help. Regards, Charlie On 21 February 2011 22:17, Rick Mann <rm...@latencyzero.com> wrote: > 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/charlief%40cellcastonline.com > > This email sent to charl...@cellcastonline.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
