Technical Q&A QA1042

Menus & Hardware Accelerated OpenGL under Mac OS 9 Carbon

Q: What can be done to prevent asynchronous OpenGL animation driven via a Carbon Timer from drawing over menus?

A: There are two cases to discuss in handling menus and asynchronous animation.

- Using Carbon Events

- Using WaitNextEvent

Carbon Events:

One needs to support two events and toggle animation when these are received. kEventMenuBeginTracking and kEventMenuEndTracking indicate when the menu is being drawn for normal menus, pop-up menus and contextual menus (which may actually track outside the window bounds). When the kEventMenuBeginTracking event is received the application should stop any asynchronous OpenGL animation. This is best achieved by setting a flag for your timer callback to read and not animate. One can still respond to update events as the application normally would. When the kEventMenuEndTracking is received re-enable the applications animations and proceed as normal

WaitNextEvent:

One wants to stop animating when receiving mouseDown type events whose part code is inMenuBar. Also do not initiate any contextual or pop-up menus which are under application control without toggling the hardware accelerated animation off. Once the MenuSelect, etc. function has returned, it is safe to animate once again. This will take care of most cases but will not handle system initiated pop-up type menus such as on a navigation services dialog. These situations can be handled on a case by case basis by toggling the animation off prior to bring up the system dialog.

These techniques allow simple handling of the deconfliction of Mac OS 9 menus with asynchronous hardware accelerated OpenGL blitting.

Mac OS X, of course, handles this integration automatically and does not need any of these techniques.

[Jul 10 2001]