[GEM-dev] call for compilations

[zmoelnig at iem.at]

Zitiere cgc <cgc at humboldtblvd.com>:

> 
> On Jan 7, 2004, at 7:21 PM, tigital at 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