Mike Pinkerton wrote:
[EMAIL PROTECTED]">Embedding does have an nsMacWindow, though, because it's a root level window, it's a problem and we need something else. I'd like to help out with (or do) this.Given all the problems that we've had with our open file transport
counter and chugging down 75% cpu, I've decided to take another look at
moving our carbon/osx bits to the CarbonEvent model which basically uses
callbacks to get events instead of polling with WaitNextEvent.
The way our current architecture is set up, the have a "message pump"
that runs the main event loop. Embedding applications can use ours or
write their own (i assume they write their own). After some
preprocessing (closing popups, etc), the event is sent to the message
sink which then just funnels the event to the appropriate nsMacWindow
and its internal nsMacEventHandler.
The CarbonEvent model is more window-centric in that you install event
handlers on particular windows to handle clicks, keys, activates, etc.
As a result, the most events would go directly to the window registered
to handle the event and not through a central pump/sink. I beli eve this
shouldn't impact embedding for a couple of reasons:
- embedding doesn't have a nsMacWindow (or does it?) where the mouse/key
the events end up
[EMAIL PROTECTED]">I think what we should do first is switch from nsRepeater to Carbon timer events. The real problem is that we're having to compute the minimum sleep time to pass to WaitNextEvent() so that we idle often enough and call DoIdlers() and DoRepeaters() often enough. Computing the sleep time accurately using nsIIOService (I think that's what we're doing) is expensive and doesn't do a great job (why we still are using 75% of the CPU doing nothing). Getting rid of this polling/repeaters model would do the most good and it could happen independently of other event processing changes. Also, the embedding app does have to call these nsRepeater functions from its event pump. Doing it with Carbon timer events would free it from this responsibility.
- for these kinds of events, the pump/sink machinery is just overhead
that simply funnels the event into the event handler on a particular nsMacWindow
There is a mechanism to handle events at the application level, and
that's probably where we'd want to handle timers and some idle event
processing. I haven't looked too closely into that yet, but I'm pretty
sure it's nothing complicated.
I really just wanted to throw this out there before I got too far to see
if anyone (Conrad?) had any serious concerns or objections. I don't want
to get rid of the pump/sink machinery, only avoid it where advantageous.
Obviously embedders would still fire events into the sink from their own
event handlers and so we'd have to make sure to keep the event
processing separated so it's reusable between the embedded/non-embedded case.
I have to study how Carbon Events are used within frameworks like PowerPlant as well as non-framework apps to see how to make the best fit. I think we still want an event sink but one with finer granularity. While we could have a one-size-fits-all HandleEvent() method which handles any event, we might be better off specializing specific events. I'll look at it.
-Conrad
[EMAIL PROTECTED]">
On a side note, should we have a new interface for the message sink for
carbonEvent-based embedding apps, given that EventRef you get from
carbonEvent-based apps is opaque?
