tigital@mac.com wrote:
hi IOhannes,
...I haven't had the time to check your latest cvs additions, but I do have some lingering questions regarding how [gemmouse] and [gemkeyboard] work, so that I can get them working on OSX...It appears on both linux and windows, some kind of event callback is installed during gem window creation; but I don't see how/where this is getting hooked into the various callbacks for mouse and keyboard input? Could you elaborate on what's going on here?
well, it is hard to see, as it is spread over various files different for various platforms.
basically this means: Windows: all the magic is done at window-creation-time in GemWinCreateNT.cpp the function craeteGemWindow() specifies the even-handler MainWndProc() (i guess) this is a callback from the OS
X: unfortunately the X-code is hidden in GemMan.cpp, in the function dispatchGemWindowMessages() (of which there are 3 versions, one for each os - urgh!) so we do not rely on a callback here but rather poll the event-queue.
Once I get this done, then I'll say "let's release"! Otherwise, it's just not finished...
right, i just thought it would be good to feel some pressure again ;-)
thanx, jamie
mfg.as.dr IOhannes
On Monday, January 5, 2004, at 04:47 PM, IOhannes zmoelnig wrote:
X: unfortunately the X-code is hidden in GemMan.cpp, in the function dispatchGemWindowMessages() (of which there are 3 versions, one for each os - urgh!) so we do not rely on a callback here but rather poll the event-queue.
...ok, this helps alot: I didn't see this dispatchGemWindowMessages(): I guess I can throw the event checking in there, like the linux code, and do an InstallEventManager() at window creation...I see that it's only "called" once in GemMan:createContext():
s_windowClock = clock_new(NULL, (t_method)dispatchGemWindowMessages);
...I'm not familiar with clock_new(): what is this setting it up for? I'll have to admit I'm not as familiar with some of the underlying stuff as I should be (is this clock_new() from pd or GEM?)...
Once I get this done, then I'll say "let's release"! Otherwise, it's just not finished...
right, i just thought it would be good to feel some pressure again ;-)
...yeh, I'd wandered off from gem for awhile (into gameland: pretty much finished porting freespace1/2 and also started helping with homeworld!)...but I'm back, really!
l8r, jamie
tigital@mac.com wrote:
On Monday, January 5, 2004, at 04:47 PM, IOhannes zmoelnig wrote:
do an InstallEventManager() at window creation...I see that it's only "called" once in GemMan:createContext():
s_windowClock = clock_new(NULL, (t_method)dispatchGemWindowMessages);
...I'm not familiar with clock_new(): what is this setting it up for? I'll have to admit I'm not as familiar with some of the underlying stuff as I should be (is this clock_new() from pd or GEM?)...
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);")
mfg.as.dr IOhannes
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"...
cul8r, jamie
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
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
-
cgc -
IOhannes zmoelnig -
tigital＠mac.com -
zmoelnig＠iem.at