> I must know set up a TCP socket connection with another machine. I am usually > working on C#, which is why I am so stumped in Objective-C...
preface: I know basically nothing about C#, so apologies if I make brash statements. > Can I potentially set up my tcp connection to the target machine somwhere in > startExection or enableExecution? you can "potentially" set it up anywhere you'd like, but I'd recommend starting as far from per-frame execution as possible so that you don't harm rendering performance. enableExecution seems like a good place for that (be sure to tear down the connection in disable, of course) > Ideally, the connection should be existing and working, so that I can toss > out packets of every frame... > > Usually, TCP connection are handled asynchronsouly - how is it done and > handled in Objective-C, and, more specifically, in Quartz Composer? I > understand that this is a multithreaded application? TCP connections are handled however you configure them. They're almost-synchronous by default in C, and I'm not sure of the obj-c classes you'd use to do the same thing (NSStream perhaps?), so I don't know their default behavior. QC isn't multithreaded at all (and if you try to make it so, there are a large number of hoops to jump through to not make things blow up/leak/crash). If you're running inside another application, odds are you are threaded, but probably not "with hostility" -- you're probably going to be on a single thread or single dispatch queue. Just don't use TLS (thread local storage) or global variables, and you should be fine. You should probably pattern it like this (having thought about the problem for a whole 5 seconds - take this with a grain of salt): in Enable, set up the TCP connection, and a dispatch queue that targets from one of the global concurrent queues. if you're targeting 10.5, don't use dispatch (because it's not there) and just start a pthread. In Execute, get the input image stuff. vImage-ify it. Then execute a block on the queue above that sends the image over the wire and then does cleanup. for 10.5, this is a bit trickier because you'll have to manually manage a work queue (I won't discuss that at length here). have execute return immediately afterwards. This will decouple sending the image over an arbitrarily slow connection from the rendering loop (which doesn't want to have its performance degraded just because someone tripped over a cat5 cable or started the microwave to make some popcorn or whatever). You could also have logic in place to notice when you've submitted a newer frame, and the previous frame hasn't been sent yet - in that case, the network is falling behind, and you can just throw out the old frame so that the receiver doesn't continue to fall farther and farther behind. If you're on something newer (10.7 or later) you can also look into dispatch_io, which will handle the asynchronous bits for you without needing to manage your own queue (you'll still want to do some bookkeeping to keep old frames from piling up if the receiver falls asleep). -- Christopher Wright christopher_wri...@apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
