BEWARE of PLUGINS!
... You could replace "PLUGINS" with just about any executable code. There are plugins for many apps you're likely using. QC has some built-in (Backdrops for iChat/photobooth, and the ExtraPatches.plugin that gives you audio, video, QT, midi, and some other patches commonly used). Mail uses them, Safari does too. Quicklook, iPhoto, Finder, QuickTime, Spotlight.... ok, you get the idea. Being careful of them in a conservative sense is a good idea, but concluding that they're all bad is just silly.
I innocently loaded a few without realizing that they expose your entire system to potential damage, or viruses. Architecturally, QC itself is kind of like a plug-in and a more reasonable approach would be to write your own wrapper code. There is nothing that can be accomplished by a pluig-in that can't be betteraccomplished by making the 'round-trip' to some objective-c code.
Any app you download potentially exposes your system to such damage -- plugins are not granted any magical powers that normal apps don't already have. QC doesn't run with special permissions, so if it's going to do something particularly nasty, it'll still ask you for your admin password. If you're typing that into every textbox alert that comes up, you can hardly consider yourself innocent.
Wrappers around QC is wildly impractical -- sure, you can do OpenGL drawing on its context (before and/or after QC renders, no less), but you lose out on all the powerful processing pathways built into QC.
"round-trip" can be expensive, and miss out on a lot of QC's built-in functionality -- plugins have the ability to integrate with QC's graph and pipeline (including it's usually-effective lazy evaluation system), giving the plugin a distinct advantage For Free. I don't think everything can be better accomplished by an external piece of code, for these reasons and others.
QC is no more a plugin than QuickTime, AppKit, WebKit, or CoreFoundation is. It's a framework and a technology (or, amalgamation of technologies in QC's case) used to accomplish specific problems.
Plugins are an absurd and ridiculous technique for any discussion of performance and that shouldbe clear to anyone who has a bit of system experience.
This statement is ridiculous: hundreds, if not thousands, of QC users know nothing of code, and don't care to learn any. For that large audience, making a performance improvement makes their life easier/ better, even if QC isn't the ideal solution to what they're trying to accomplish -- QC may very well be the only solution available, so it becomes the defacto best solution. Furthermore, as noted above, Stock QC (totally unmodified) loads at least 2 plugins at startup -- Apple chose to do it this way, rather than place the code into the QC framework. If the performance "hit" for doing such a thing was severe, one would think that Apple would choose a different route. The fact that they have not (after 2 generations of QC), along with significant empirical evidence, leads me to believe that there is no significant performance hit under ordinary circumstances.
(now, you might be able make a case for gcc making slower dynamic code than static code, but that's pretty picky and there are ways around that...)
They do represent a way of packaging some code for sale, and I suggest that you wait until the AppStorehosts these as a way of ensuring a 'trustworthy' source.
AppStore cannot guarantee (or "ensure") safe code, it can only create a paper-trail to the distributor. In other words, a malicious program can still be distributed via the AppStore. Code signing allows you to hold a key-holder accountable, but that's still pretty thin for truly trusted code -- until photo ID and a public notary are required for such a certificate, any random programmer can get such a cert and start releasing things.
I don't believe that there's an AppStore for QC plugins in the near future, though I could be mistaken. The plugins I've seen that do dangerous stuff are pretty clearly marked, and most are open-source anyway. I've yet to see any serious plugins available that have non- responsive developers (at kineme, for example, we take being responsive to the community extremely seriously -- any of our users can vouch for that). Many plugin developers that I've talked to/ worked with personally even lurk on this list, with varying levels of activity :)
I might also point out that they are written in objective c and pehaps should be discussed on anothermore appropriate list.
"quartzcomposer-dev" -- developing QC composition, or its plugins I guess. I agree that there are two distinct sides to QC now, though I'm not sure I agree with the idea that those groups should be separated -- there's a lot to be gained from those who know the insides, and there's a lot to be gained from those who make brilliant compositions (I know I've learned a thing or two about how users want things to work based on how they structure their compositions :)
Since QC has introduced no new graphics format, performance questions might be also directed to the respective lists (quickTime,Cocoa-dev). So far, plug-ins has given license for someone to talk aboutcompletely unrelated issues, under the rubrik of QC.
There's a QC-specific api that is not addressed by any other list. "Completely unrelated" is too generous -- they're plugins for QC, after all, so they're quite related to QC development (just internal rather than external, see previous point).
Further, there is a new format: QCImage (it's an opaque datatype internal to QC, but there are places where such objects can be used outside of QC), and the original question of this thread dealt with getting data in to/out of such an object (in an official-api kind of way, no less).
Cordially, Christopher Wright -- [ christopher wright ] [EMAIL PROTECTED] http://kineme.net/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
