Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Darwin disk I/O - better interactive response

>Some applications do quite a bit of work to update the contents and enabled
>states of menu items. Pushing from the app to the window server every time
>the state changed could potentially be a performance hog and decrease UI
>responsiveness.

I don't see how it can be any less responsive than pushing graphics calls.

The window serve rlies between the application and kernel, there would be no delay which is why I suggest the code be placed (or should I say executed) here.

>The new Carbon Event Model was specifically designed to make menu updating
>even more "lazy" than the old Mac OS event model to help responsiveness.
>Events are sent to the application just before each menu and sub-menu is
>displayed.

Carbon events were specifically designed to reduce event polling. I don't see how this can be considered lazy. Event manager was invented before there was a System, it was just one 'app' executed by the Finder at a time. Carbon events should have been implemented in System 7 IMO.

>At the very least, pushing to the window server would have to be an option,
>available for menus that do not require much work to update, not a
>requirement.

Making it an option would defeat one of the primary advantages in that all the menu structures would exist in one location.

Anyway I think this is becoming dangerously off topic, feel free to take this up with me personally.

References: 
 >Re: Darwin disk I/O - better interactive response (From: Chris Page <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.