Hi Vade and others:
On 23-Oct-09, at 3:43 PM, vade wrote:
how will performance suck if stop/start is only called once per
scene graph??
Because it all has to be re-allocated each time you click "start" and
torn down when you click "stop". That isn't the same as allocating
everything in -init and gaining an exclusive lock on hardware in it so
it doesn't have to be done again.
Unless your app is constantly building up and breaking down
QCRenderers every frame (which is frankly stupid), you will get this
"stall" when the device is configured only once, and any time the
user re-configures it. No other time. Ever.
I'm not doing that in -execute, which would be excessively stupid like
you pointed out.
However it is being called multiple times within the time a Plugin
exists.
Each time the Player "Start" button is clicked on the -startExecution
message is received.
Each time the "Stop" button is clicked the -stopExecution message is
received.
So it's doing this more than once for the plugin.
And I wanted to verify this behavior in the plugin before I reported
back here just to make sure my trace notes were correct.
We've given you a few valid possible work arounds but it sounds like
you want it to work one way; the way it apparently wont work.
Although I appreciate what people have suggested, none of it appear to
be very close to working much better than what we have out there
already via the QC Video QuickTime Plugin, and accessing our DFG VDIG.
What do you mean no one is bringing in audio or video hardware into
QC? I can successfully talk to plenty of video input devices using
QC, or send textures/frames out to them via QC.
Are they building their own QC Plugins for devices or just relying on
the Apple Quartz Composer "Video" Plugin?
In version 3 and higher of that Plugin the "Settings" button was
removed which means the Video Settings dialog can not be called to
allow the user to configure AV devices. Thats' the primary reason I
wanted to do this was because Apple removed the setting button. And
why they removed it is clear to me now.
Honestly, Its starting to look like you want something to complain
about... but at this point thats your problem and not mine.
Let's go over the options we've explored because I don't see a single
one that is significantly better than what we have relying on the
Apple Video plugin calling our VDIG directly.
Method 1) Find, open and exclusively lock onto a DFG hardware in the
QCPlugin -init call, which allows me to use the
QCPlugInViewController for the GUI interface which I have already
setup up 90% of the functionality for it. This is the ideal situation
and deals with everything I had hoped to achieve. The limitations on
this are:
1a) Will not work can't because -deallocate is not called and never
will be reliably called, so the device can't be closed down and
everything properly released so it doesn't leak like a sieve.
Method 2) Do the allocation in QCPlugins execution section ,so that
the -startExecution finds, opens, allocates configures to begin
streaming video. Then tear it all down in the -stopExecution phase and
release it. This happens each time the user clicks on the Stop / Start
buttons. The limitations on this are:
2a) No exclusivity to the device once -stopExecution is called. The
device could be claimed by another plugin in QC or by a QuickTime
Video application (i.e. iChat, Photo Booth BTVPro, Security Spy FCPro
etc.). There is no way to guarantee that the device is accessible the
next time they click on the "Start" button. That makes this a crap
shoot for reliability.
2b) no configurable GUI interface because the QCPlugInViewController
is set up by the -createViewController. If the "-startExecution" was
not called, then there is no device to change settings with and it
fails to load. This is likely the reason Apple removed that "Settings"
button in the first place.
2c) You can not use inputs because inputs can not be allocated in the
execution phase, as pointed out by Troy. I also can't see users' being
happy having to set up multiple patches attached to the DFG inputs
just adjust the brightness or contrast or sharpness etc.
2d) It will have a performance hit each time time "-startExecution"
gets called because it has to do a tonne of work finding, allocating,
configuring and starting a device each time.
Method 3) Do the DFG allocation with -startExecution and bypass the -
createViewController by create my own GUI window for device control.
Then dispose of the window and the DFG when the -stopExecution is
received. This at least deals with issues 2B and 2C. To me this is the
least objectionable scenario that doesn't leak objects and memory. The
limitations on this are:
3a) - same as problem 2a) - no exclusivity to device.
3b) User has to deal with this window being in their face each time -
startExecution is called and within the composition each time they
"start" it playing. If they close the window, they have to stop /
start the composition to get the window back.
3c) same issue as 2d) - performance concerns.
So what am i missing here? I don't see an elegant solution that makes
good use of Quartz Composer plugin abilities and doesn't look like a
kludge.
Method 4) Don't build a QC Plugin. I could build a simple app to write
a preference file into the user pref folder for each DFG and if it's
present the DFG VDIG will load it up the last settings used and then
the device only applies those settings until the pref file is removed.
It's clumsy, draconian and frankly user hostile, but it's very close
to being the same as doing with a Quartz Composer plugin.
The things I need in a Quartz Plugin solution are:
1) Exclusively claims the hardware so no one can steal it behind my
back until the plugin is finally released.
2) Doesn't leak the objects memory and properly cleans up after itself
so that I can clean it up programatically.
3) Has an easily configurable GUI presented to the user when they WANT
to access it - not foisted on them each time.
4) Doesn't require Inputs to configure basic functionality that they
will only occasionally need to access it. For example, brightness,
contrast etc. type settings are usually set once and then forgotten..
I have a perfectly good non QuickTime API for the DFG developed that
does everything needed to support the Plugin, including automatic
preferences loading and saving by the device serial number (making it
so it can start back up EXACTLY as it was last used), but I'm
struggling to shoe horn my needs into a QC Plugin.
Constructive suggestions appreciated.
Have a great weekend..
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
_______________________________________________
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]
