how will performance suck if stop/start is only called once per scene
graph?? 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.
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.
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.
Honestly, Its starting to look like you want something to complain
about... but at this point thats your problem and not mine.
On Oct 23, 2009, at 5:29 PM, Milton Aupperle wrote:
On 23-Oct-09, at 2:57 PM, Christopher Wright wrote:
Another option that I have done in the past with a web -> image
plugin, is to alloc a brand new window manually at init, and then
have a boolean input port that triggers the window to be made key
and ordered front. This allowed me to get around my limitations
of the setting info pane not being made available in a QC powered
app, and was able to set it and fiddle with it outside of
executeAtTime.
Okay. And how does your window get disposed of?
Your Plugin never receives a "-close" or "-finalize" call after
the -init" phase of the QCPlugin to tell it it's shutting down.
So is it leaking a window each time it's used?
We've already been over this: - (void) stopExecution:
(id<QCPlugInContext>)context; is called when QC is shutting down
(at least the context the patch is being used in). Whether or not
vade's closing the window is at his own peril, but leaking is not
implied nor required.
See his next post about leaking windows because -dealloc is never
called.
And I don't care if that's 4 bytes or 4 megabytes. A leak is a leak
is a leak and degrades system integrity.
This is _The_ time to release any resources in use by your patch,
as the patch can't possibly get reused once this method is called
(the graph is getting deallocated, any parameter views are already
closed, etc).
That is not the case!
How does the -createViewController method set up the
QCPlugInViewController panel to allow users to configure the device?
And if the device is open in the startExecution, then the
QCPlugInViewController can not open and configure it because it's
open already. And if it's opened by the QCPlugInViewController then -
startExecution can't access it and it fails.
The device has to be accessible to the QCPlugInViewController,
QCPlugInOutputImageProvider and the QCPlugIn for it to work properly.
And as Troy pointed out you can't create inputs from within the
Execute part, so inputs are a dead end for the user configuration.
Ever wonder why Apple removed the SGSettings buttons from the panel
for setting QuickTime video settings in QC 3 and higher? It's
because of this mess.
- (void) stopExecution:(id<QCPlugInContext>)context; is called
exactly once (per patch instance), when the patch is going out of
commission.
- (void) startExecution:(id<QCPlugInContext>)context; is called
exactly once (per patch instance), when the patch is added to a
particular composition.
And as I have said multiple times, performance will SUCK if you do
this and it also has other operational issues too.Such as another
patch or driver pulling the device out from under you because you
have no exclusivity to it. Not being able to determine which device
they want to use, not being able to configure the device - the list
goes on and on..
If "this" the only way this is "supposed" to (not) work, well then
this is done and explains why no one will bother bringing Video or
Audio hardware to Quartz Composer.
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/doktorp%40mac.com
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]
