Re: stack problems kinda figured out

Paul Chen (chen@geoworks.com)
Thu, 2 Jan 1997 10:29:13 -0800 (PST)

GWRepNate writes:
>
> In a message dated 97-01-01 19:56:17 EST, GWRepCami@aol.com writes:
> > @call newPrim::MSG_GEN_SET_USABLE(VUM_DELAYED_VIA_UI_QUEUE);
> > @call newPrim::MSG_GEN_SET_ENABLED(VUM_NOW);
>
> Unless you have some timing issues to worry about, you should always be
> using VUM_DELAYED_VIA_UI_QUEUE, all of the time, every time. It makes the
> draw update a little faster since GEOS can optimize the graphics instructions
> when it has them all together at once.

Again, you'll want to use VUM_DELAYED_VIA_APP_QUEUE. Below is an
article from the Geoworks Developer Support Knowledge Database on
VisUpdateModes. (You can search the Knowledge Database yourself!
Go to www.geoworks.com, click on Developer Relations --> Technical
Support --> Knowledge Base. You can search for keywords, or browse
the entire database.)

========================================

Summary: How to use VisUpdateModes
Keywords: VisUpdateMode, VUM_NOW
Access: ALL:PUBLIC
History: 961016 eballot,961018 eballot

Here is a brief description of how and when to use the various
VisUpdateModes.

VUM_NOW:
Use this sparingly! If you have a *single* object
to update, you may use it, but it generally causes a huge
number of geometry invalidations and recalculations to
occur in your application.

The easiest way to screw things up is to use VUM_NOW
indiscriminately. When in doubt, you should use
VUM_DELAYED_VIA_APP_QUEUE; intuitively you might think
it would be slower, but in pratice you're often doing
multiple updates, so it's usually as fast or faster than
VUM_NOW.

VUM_DELAYED_VIA_APP_QUEUE:
This is the mode you should use if you are invalidating more
than one object. For example, if you are changing monikers
for each item in an item group, you should pass this mode
along with MSG_GEN_REPLACE_VIS_MONIKER.

This causes all the geometry invalidations/recalculations
to occur at once, which is much faster and less prone to
race conditions.

VUM_DELAYED_VIA_UI_QUEUE:
This one should not be used unless you are doing something in
the system's UI thread, in which case it is used in the same
context as VUM_DELAYED_VIA_APP_QUEUE. In fact, VUM_NOW is
rarely used in the UI: using it during updates can result
in infinite recursion.

VUM_MANUAL:
This one is typically used for synchronization between
threads. For example, if you have objects that are being
updated on your UI thread, but you must wait for your process
thread to finish doing something before displaying the results,
you should use this mode, and then do the invalidation
yourself.

Use VUM_MANUAL with caution! It's easy to forget to do the
invalidation, in which case your app will be in an
indeterminate state.