Hello Gordon, I don't know much about using QC in views, but in my experience you encounter a performance optimization problem: The Composition is only rendered, if anything is changed which drives the output: QC is starting at the rendering patches (Billboard / Sprite) and check their inputs, if anything has changed. This is done by asking the connected patches which feeding the inputs of the rendering patches. if their inputs didn't change either, they don't get processed. This runs recursively upwards until your published inputs "mouse x" "mouse y", what have you. If you don't change "mouse x" or "mouse y" the composition don't get rendered again. You see this effectt with JavaScript patches dramatically, because they only get processed if their inputs changes. Which makes it necessary to connect a dummy "Patch Time" patch to any input of them if they are depending on timing. Also "Patch Time" is not the best choice sometimes, because its time output value is driven by the enclosing view. AFAIK you can set the rendering time to any value you want and so you can run the timing backwards for example. You should use the "System Time" patch if you want to make sure, that everything is rendered all the time.
Another thing is your "first frame missing" problem: QC is performing a first test run on the complete composition in order patches can setup things before the actually rendering happens. This is expressed by the variable "_testMode" in Javascript. You should test against this variable if your are running in this first test cycle or not in JavaScript. I don't know if this happens outside QuartzComposer Editor too, thought. Maybe you have to render the composition twice upon first start. best, Achim Breidenbach Boinx Software On 10.03.2013, at 22:39, Gordon Apple wrote: > More related issues. > > Some of the compositions are merely a static image, possible scaled and > shifted. These do not render at all when used in my subview, but do in the > main view. The specs state that the composition will automatically play when > the layer is installed in a visible layer hierarchy. This seems to be the > crux of the problem. In my main view, they automatically play. In the > subview, they do not, unless they have included some repetitive timing > element. In the case of a static image, I assume “play” means that the image > should evaluate. I do not understand layer timing chains. What could > possibly cause this difference between views? > > The spotlight composition, previously mentioned, is a special case where I > pass mouse position to the composition. On mouse down, I create and install > the layer. It does not render unless I ding it again by moving (mouse > dragged) or another mouse down at least one pixel different from initial > position. It then renders properly. Again, the problem is getting it to > render initially when installed. > > Another related issue I just ran into is that I realized that you don’t get > anything additional rendered unless something is continually changing. This > showed up when I implemented a trail function. The trail fades with a fairly > long time constant. Unfortunately, when I stopped moving the mouse, the > trail fade stopped and remained in that state on the screen. To get around > this, I introduced an imperceptible variation in the image position, driven > by an LFO. This seems kind of wonky. Is there another way to keep the > composition continuously rendering? > > > On 3/7/13 3:25 PM, "Gordon Apple" <g...@ed4u.com> wrote: > >> Always happens after I post something. While Googling to find out what the >> “tension” parameter was for in the Interpolator, I accidentally found out >> about control-clicking the patch bar for other options. Setting the timing >> to “local” (vs. the default “parent”) seems to have solved the problem. I >> still don’t understand why this performed differently in one view vs. >> another. The non-performing view was actually a subview of the performing >> one. It must have something to do with the timing distribution chain in the >> view/layer hierarchies. Wow! Really obscure. > _______________________________________________ > 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: > https://lists.apple.com/mailman/options/quartzcomposer-dev/achim%40boinx.com > > This email sent to ac...@boinx.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: https://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
