Zitiere cgc cgc@humboldtblvd.com:
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.
of course, i have no idea of the darwin event handling at all (but you sound very reasonable)
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
this should be the only problem that might occur. i guess implementing the gemmouse/gemkey feature shouldnt be much of a problem, since both types of event-handling (polling vs. callback) are already there (linux vs. windows), and we (hmm: you) only have to decide which model fits in better.
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.
basically i agree, but i think, that the chance of degrading the video-performance of Gem with UI-event-handling seems rather small to me (of course this is only true if we don't have to wait for the user to trigger the next rendering cycle with the spacebar (ala WaitNextEvent))
jamie: changing the event-handling structure of pd's UI might prove a bit of pandoras box, since (i believe) a lot of pd's internal event depend on it. this may be: a) plain wrong (haven't looked at the code) b) a good thing to inquire and solve (like in Gordian knot), because the UI-events shouldnt have anything to do with pd's internal events.
anyhow, it is likely to be a lot of work
mfg.as.rd IOhannes