I appreciate the idea, but I have already considered, looked at and
discarded this as badly flawed.
It isn't going to work for several reasons.
1) Most Video devices allow the user to configure them (i.e. adjust
exposure, color balance sharpness bit depth etc.) and see feedback of
what they are doing in the video preview. The only way to do show the
controls is by creating a "QCPlugInViewController" and that's done
within the -createViewController method of the QCPlugin and you need
to pass it a reference to the video device object so it can talk to it
when it gets created. In some cases (first time start up) , you have
to use the panel to start using the device (for example selecting
which device to use if there are multiples available), especially if
there are no preferences created.
So we have a catch 22 situation here. The device doesn't get accessed
from the -createViewController until the -startExecution method gets
called because it hasn't been opened yet and -createViewController is
already allocated by the plugin so it's all set to fail!. And if
device is released in the -stopExecution call, then it once again can
not be accessed at all in -createViewController. This is just a very
poor user experience - I expect Apple to be better than this kludge!
If you have used QuickTime Video for controlling camera, you know what
I'm talking about with configurable devices and how users interact
with them. This architecture has only been around since 1991 (that's
18 years ago) so I would have expected Apple to learn something from
it's own products before introducing a new broken mouse trap.
2) You will have really horrible performance with the plugin on
starting in -startExecution and stopping in -stopExecution because of
all the work (finding hardware, querying hardware, accessing hardware.
configuring hardware, memory allocation etc. etc. etc.) that needs to
be done behind the scenes to get the devices up. I work with USB,
FireWire, PCI, CardBus, GigaEthernet and ZoomedVideo hardware and and
this one shot approach adds a whole bunch of latency that will be even
worse than the VDIG experience in QuickTime was back in the 1990's.
Why would I inflict such poor performance on my user base?
3) It will not work at all when the user has multiple devices attached
and wants to use them. In most cases the user with selecting which
device to use in the User in the "QCPlugInViewController" interface.
So if we have 2 instances which are both stopped with -stopExecution,
the user could select the either of them for use because they are both
released. When they go to start the device in -startExecution the
second plugin may suddenly have the device yanked out form beneath
their feet. The proper way of handling this is to have exclusive
access to the hardware when the -init call of the QCPlugin is first
done, which guarantees the user will be able to use the device they
want to use for the duration they are using it in. Otherwise you have
another really crappy user experience!
So unless Apple actually fixes it's app and architecture, this is
doomed to be a complete support nightmare that I have ZERO interest in
inflicting on my customers or myself.
Milton J. Aupperle
President
ASC - Aupperle Services and Contracting
Mac Software (Drivers, Components and Application) Specialist
#1106 - 428 Chaparral Ravine View SE.
Calgary Alberta T2X 0N2
1-(403)-453-1624
[email protected]
www.outcastsoft.com
On 22-Oct-09, at 1:47 PM, Christopher Wright wrote:
That means you can't programatically release the hardware nor any
other objects or buffers allocated when the plugin is initialized.
While I completely agree that -dealloc isn't reliably called (or at
all, under most circumstances), and that that's a bug, there is
still a way to programatically clean up:
- (void) stopExecution:(id<QCPlugInContext>)context;
Under the Discussion section of the documentation for this method,
you'll find the following:
"Discussion
The Quartz Composer engine calls this method when it stops
executing. You can optionally override this execution method to
perform cleanup tasks."
(from http://developer.apple.com/mac/library/documentation/Cocoa/Reference/QCPlugIn_Class/Introduction/Introduction.html#/
/apple_ref/occ/instm/QCPlugIn/stopExecution: )
It's not dealloc, and it's definitely not following the standard
Cocoa conventions for cleanup, and their own examples certainly
don't reveal this quirk at all, but I've found that -stopExecution:
is effectively equivalent to -dealloc (in terms of cleaning up
object-managed resources), and it is reliably called.
Further, outside of the QC editor, -dealloc /is/ reliably called
when a QCComposition is released. So it's just the editor that has
retain/release issues, not the underlying QC framework itself. (so
other apps that use QC aren't going to run into problems).
--
[ christopher wright ]
[email protected]
http://kineme.net/
_______________________________________________
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]
