In a large application, the performance cost assocaited with computing menubar dimming,
checkmarks and override text (such as Undo) is prohibitive to perform at each pass on
the user interface loop. This is especially true for menu item that reflect summation characteristics
of large material. For example, a larger spreadsheet selection needs to scanned to check for
bold-ness and set/clear the checkmark in the user "pull-down" attributes menu. In a real-time
financial spreadsheet, this would have to be done each time a cell was delivered t to the calc engine.

This is clearly a huge waste unless the user happens to go the to th Attributes menu as the at
 the next new action.

What is needed is for the AWT layer to call an optionally supplied method the MenuItem.
Such method MenuItem.willDisplay(), would get called after the user does an action that
will cause the menu to be displayed, but before the menu is actually displayed. In
concrete terms after the button press in the menubar. The api should be recursive in
the sense that it is called once permenu and once per menu item.

There is a legitamate workaround in owner-draw [if supplied] only if we are able to
access the same fornt and related (checkmark...) attributes that the native look uses.
This is not currently possible on the NT platform where the menu font is not available
to AWT.