MOTIF RUN-TIME ISSUES

• Use at most one GL widget in an application. Having more than one GL window in your application is very expensive because a GL context switch is quite heavy-weight.
• Take proper advantage of workproc's.
  • Example: the interactive performance of sliders in the color chooser was terrible until the slider processing was moved to a workproc. Then the performance became just fine.
  • Example: if a little-used UI component is called, it may pay to at that time use a workproc to create related ones that the user is likely to need. Then they can be quickly mapped when requested.
  • Note: do not remain in a workproc more than a fraction of a second without ensuring that events get processed. This point is discussed in more detail below.
• Reuse components, such as dialogs, wherever you can. Do not create them as needed and then immediately destroy them when done. Instead, save their ID and unmap them. They can be quickly re-mapped later when needed.

  Note that this suggestions is consistent with creating most UI components (other than the initial UI) in workproc's.

• Wherever possible use the first of these that you can:
  1. Use map/unmap to make ui components come and go. This has always been good programming practice.

     As of the current level of Motif, with its need to keep drag and drop information up to date, failing to do this has become much more expensive than it used to be.

  2. Use manage/unmanage to make ui components come and go, only if you really cannot just map/unmap them.

     This is significantly inferior to map/unmap, but if the geometry really is changing may be necessary.

     If you are affecting much geometry calculation, bracket your operation with XmDropSiteStartUpdate and XmDropSiteEndUpdate.

• Use create/destroy as a last resort. This is quite expensive. It should only be done once -- preferably at a time the user isn't waiting for it.

  If the user does something that needs a new UI component up, you should normally be able to just map one that was either used before, or was created anticipating this need. If the user is doing something unusual, you may need to create a new one -- but that should not be the common case.

  Any time you do create a component, save it if it might get used again later. It will be much cheaper to remap it, possibly setting some hew resources first, than to destroy it now and create it again later.