On Tue, Sep 14, 2010 at 12:32 PM, Christopher Wright < [email protected]> wrote:
> > Is a trackball supposed to work inside of an RII? > > I seem to remember that it has in the past, but I'm not 100% sure. It's > definitely not working for me in Snow Leopard, and I'm curious if this is > supposed to be the case. > > This is a known bug with how QC's execution modes work -- basically, QC > knows it needs to execute if a provider is there, but the trackball is a > consumer -- provider, processor, and consumer are mutually exclusive. > That sort of boggles my mind! Outside of a render in image, a trackball is still a consumer, and the macro that it's "in", the qtz/QCPatch, is also a consumer... so by this logic, it seems amazing it works at all. In Leopard, attaching mouse to "something" isn't enough to coax evaluation every frame, and neither is attaching a still image to the cube. I actually have to go so far as to do something like render a video feed in the RII, or using an interpolation somewhere. Which brings to mind the thought that a RII should seemingly be an external provider, not a processor patch. I know that it is possible to make a external provider macro (tested earlier today), but I don't see how to provide image out, or to have it "render" stuff inside of it (I suspect that is totally impossible). Both those things are sort of over my head, and undocumented anyway. <rdar://problem/5547810> > > > In a moment of thinking about how QC works though, I thought that it > might be possible that placing a Mouse patch inside of the RII along with > the Trackball, but not connecting it to anything, might coax mouse events > into forwarding correctly. For me, in my install, it does. > > Is this the same for others? > > This is the behavior on 10.6. On 10.5, you need something that executes > every frame to get trackball working inside a Render In Image (if I recall > correctly) > I see that there is a report for the bug, but I wonder if I should make a number of separate entries. I think the RII should be an external provider, and that it shouldn't result in evaluation outside of the current pixel w/h, if it's going to be an environment with image out? It seems like if I have an object outside of the current area able to be viewed, or one renderer is covered by something else, that RII should provide this kind of performance optimization. If I alter the projection, I can already get it to 'not render' things at certain values, so it is obvious that QC is already making some kind of assumptions to make the graph more efficient, just clumsily, and in a way that results in visual problems. This seems doubly true that it should go in this direction of intelligent evaluation optimization if it's already not evaluating unless a patch is making "something happen", like in this trackball case, or the case of coaxing a sprite or mesh not to render in an RII when it should (if you don't have an example, I'll put one together). If RII doesn't facilitate the rendering of only the specified area and subsequent optimizations that one would expect (like a crop would) it seems like there should be a Read Pixels type of stock patch, as this may make more sense than RII for grabbing the current QC Viewer image and doing some kind of image processing. Is that a reasonable feature request? Originally this kind of function worked by placing a patch at the lowest layer of a composition, and you would get an image output (Render To Texture / Render Offscreen). So, you place it at the lowest layer, then it "asks" for all of the other stuff to evaluate, and you get an image output. Even though there wasn't a trackball in that era, it seems like that kind of schema would sidestep this trackball issue (and be somewhat similar to a read pixels, come to think of it). Also, RII has no support for MSA, which doubly makes me think that QC have an object that grabs the pixels from the Viewer and provides an image out, as aliasing is highly undesirable, and it's not reasonable to have to "brute force" AA something with the RII when GPU multisampling is possible. -George Toledo
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
