On Jan 7, 2004, at 7:21 PM, tigital@mac.com wrote:
On Wednesday, January 7, 2004, at 03:06 AM, IOhannes zmoelnig wrote:
have to admit that i had to search for it too when answering your last mail. anyhow: clock_new() is the pd-timer and is declared as: EXTERN t_clock *clock_new(void *owner, t_method fn); dispatchGemWindowMessages() is called every 10 milliseconds when the window is created. (calling itself with "clock_delay(s_windowClock, s_windowDelTime);")
cool...so I don't actually need to use this on OSX, right? I mean, assuming that I use the osx carbon event model, which does it's own polling and event processing...this really makes me wanna look at polling in general throughout pd, gem, and tcl/tk, because this is kind of against the recommended "OSX way"...
I believe the clock struct needs to be used in OSX as the clock function is part of the pd scheduler and basically makes things 'go' in GEM. I really don't think dropping a Mac style event loop handler in GEM is going to be a very happy solution for managing keystrokes, mouse events and windows, but it might have to be done anyway. The only thing I've seen that would really suit is using Cocoa and NSTimer, but I have to admit that I do not know all of the details of this sort of implementation. Any sort of polling in GEM would most likely be very infrequent (less than 100 times a second), and thus probably lightweight. What must be avoided is any sort of OSX/Carbon API call that traps all events and blocks the GEM render chain from executing. WaitNextEvent would be quite evil in this situation of course, but the alternatives need careful examination to make sure that GEM isn't further burdened by UI events. I would easily vote for no key/mouse events and fast video than have UI events degrade performance, but that's my opinion and you all most likely know it well by now.
cgc
cul8r, jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev