If this follows suit, it seems like it could be important to plugin designers of render/consumer patches, and how they handle core image. It seems like it would be beneficial for Native to not be running for some custom renderers, in certain scenarios. It also might be an area that Apple might consider executing some performance voodoo on for future versions. Hard to say. I don't have a clue how designers typically handle core image coding with their custom plugins (I've not seen the enable/disable switch on anything besides the Apple billboard, to my recollection). So, I'm not sure if it is the norm to enable/disable this offhand with plugin renderers, or if it's something that isn't addressed in this way at all.
The billboard test seems to show that if it is implicitly enabled, it could hurt performance when loading in replicate macros, and iterators in certain situations. Thanks for everyone's thoughts! -George Toledo On Tue, May 19, 2009 at 10:35 AM, Patrick Sheffield < [email protected]> wrote: > Native ON, I get about 30 fps. Native OFF, I get about 60... > Patrick > > On May 19, 2009, at 3:48 AM, George Toledo wrote: > > That conclusion definitely fits my observations. I don't know if that will > hold true, but for now, it seems very fit. If that is correct, then it > explicitly explains the performance differences, and the exceptions to the > rule. > I've attached a file. This is not something I would typically do (because > the renderers aren't being used to impact the visual), but fits in with what > you describe. Except, in this case, each billboard would be a rendering > destination, so all of the calculations must be being done with Native > enabled, whereas, it wouldn't have to do this with Native disabled. (unless > I am misreading here) > > On my machine, with Native enabled I'm getting 2fps. With native taken off > I'm getting around 12fps. I don't know if that trend will hold true on other > systems or not. > > -George Toledo > > On Tue, May 19, 2009 at 6:29 AM, Michael Kwasnicki <[email protected]>wrote: > >> I've tested it on my iMac Early 2006 and got stable results with the test >> composition. >> No difference between native and not native CI rendering. >> But one thing that prevents me from using native CI is that on some CI >> filters the results are blocky. >> They look alike at original size (lets say 720x576 PAL video with a filter >> applied to it) >> but when rendered at full screen, native CI looks ugly. >> >> I've attached a sample composition so you can compare it. >> It runs the Max OS X welcome video at a low res so you can see the >> difference in the image quality. >> While disabled native rendering smoothes the edges out at non-native >> resolution (320x200), native rendering does not. >> (best seen on glossy of the X at the end) >> >> Now some assumptions on what I think I see: >> So I think native CI rendering is somewhat which is intended to be applied >> at native pixel size as CI filters do. >> Disabled means that it is applied to the texture in the texture size >> (320x200) and the texture is rendered with bilinear filtering. >> Enabled means that it is applied to the screen size when playing in full >> screen. >> That would also explain the contradictions regarding the performance. >> Native CI should be faster when the screen size equals the actual pixels >> to process by skipping the creation of a texture. >> And it is slower in full screen because a bigger surface has to be covered >> with a CI filter which is a waste of performance. >> Depending on the complexibility of the CI filter, disabling would provide >> a better performance in that case. >> >> Hope this somehow correct. >> >> >> >> _______________________________________________ >> 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/gtoledo3%40gmail.com >> >> This email sent to [email protected] >> > > <exception to the rule.qtz>_______________________________________________ > 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/psheffield%40earthlink.net > > This email sent to [email protected] > > >
_______________________________________________ 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]
