Sorry, that last sentence should have read, "...makes me think that QC * should* have an object that grabs pixels...".
-George Toledo On Tue, Sep 14, 2010 at 9:37 PM, George Toledo <[email protected]> wrote: > > > 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]
