[GEM-dev] call for compilations

[cgc]

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.  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 at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev