[Developers] impact of EMObject callbacks on performance

[Jaap Glas]

Dear all,

For those wondering why operations on e.g. horizons can sometimes become
incredibly slow, and everyone interested in the internals of OpendTect.


ABOUT THE IMPACT OF EMOBJECT CALLBACKS ON THE PERFORMANCE OF OPENDTECT

Every EMObject generates callbacks to notify other parts of OpendTect about
changes that were made to this object. This mechanism is for instance used
by the visualization part of OpendTect. It wants to be informed about any
modification to a horizon or other EMObject currently displayed, so that
it can perform a refresh of the scene.

Two types of callbacks need to be distinguished. One type originates from
the EMObject itself ("notifier" in EarthModel/emobject.h). The other type
originates from the geometrical elements onto which the EMObject has been
built ("movementnotifier" and "nrpositionnotifier" in Geometry/geomelement.h).
These latter callbacks are mainly caught by the lower visualization part
(visBase) of OpendTect which propagates the changes to the graphical
interface for a redraw. The former callbacks are caught by several other
parts of OpendTect among which the higher visualization part (visSurvey).
After modifying a horizon for which "Display sections only" was selected
for example, this part will have to recalculate the intersections with all
planes in the scene.

It is important to know that geometrical changes to an EMObject generate
individual callbacks for every geometrical position involved. Without some
extra programmer attention, these callbacks can seriously degrade the
performance of OpendTect when performing multi-position operations like
horizon tracking or editing. Refreshing will be initiated after every
callback, since it is unknown whether more callbacks will follow. This
becomes a real burden if each /local/ geometrical change involves a
/global/ recalculation and/or redrawing operation. There are two OpendTect
constructions that enable the programmer to transfer his/her knowledge
that a possible sequence of callbacks is dawning.

1) blockCallBacks( bool yn, bool flush ) from Geometry/geomelement.h

    Geometrical positions for which individual callbacks should have
    been activated are temporarily stored, and the whole list will be
    encapsulated in a single callback at flush time. The performance
    improvement comes from the fact that the lower visualization part
    will only trigger a screen refresh at flush time. It is advised
    to execute a flush regularly in order to avoid memory problems
    and show the user some progress on screen.

2) setBurstAlert( bool yn ) from EarthModel/emobject.h

    A special burst-alert callback (EM::EMObjectCallbackData::BurstAlert)
    will precede and terminate the flood of callbacks from individual
    geometrical positions. Any OpendTect part catching these callbacks can
    decide for itself to act on every callback immediately or wait for the
    terminating burst-alert callback first. Look at the implementation of
    EMObjectDisplay::emChangeCB(.) in visSurvey/visemobjdisplay.cc. to
    see how the higher visualization part postpones some of its actions
    in between two burst alert callbacks. As a result of this, the seed
    points of a horizon will be redrawn only once, and the same holds
    for the recalculation of its intersections with other planes in the
    scene in case "Display sections only" is turned on.

An example on the application of both constructions can be seen in the
function Horizon::setArray2D(.,.,.) in EarthModel/emhorizon.cc. It fills
the z-value fields of an existing horizon from a 2D array. In case this
horizon is currently displayed on screen, let alone with the option
"Display sections only" turned on, the function would take ages to
terminate without those two constructions to regulate the flood of
callbacks.

Finally, note that using the NotifyStopper class (see Basic/callback.h) is
not an option in such cases. Although some parts catching the callbacks will
only use them as a trigger for some global refresh, it can never be excluded
that another part of OpendTect will actually apply the geometrical position
encapsulated in the callback. Temporarily stopping the callbacks without
buffering will have these vital pieces of information disappeared forever.


Ajuus, Jaap.

-- 
-- dr. Jaap C. Glas
-- Software Engineer
-- dGB Earth Sciences
-- Nijverheidstraat 11-2
-- 7511 JM Enschede, The Netherlands
-- jaap.glas at dgb-group.com
-- http://www.dgb-group.com
-- Tel: +31 534315155, Fax: +31 534315104