Pad++ Programmer's Guide

EFFICIENCY

Several techniques are used internally for Pad++ to work efficiently, even when there are large numbers of items. Understanding these techniques may help the application designer build faster programs. The techniques are:

Pad++ renders the scene at different resolutions depending on how much time is available. For example, while panning or zooming and during other forms of interaction, Pad++ attempts to render the scene as quickly as possible. It does this by not drawing items that are very small, and drawing larger items at lower resolution. When the interaction is over, after a short pause, the system refines the scene a bit at a time, until it is drawn at its highest resolution.

These iterative refinements each have numbers. Refinement level 0 (sometimes referred to as render level 0) is the fastest, and thus lowest-resolution rendering. Each ensuing refinement is labeled with the next larger integer. The starting refinement level (which is usually 0) can be controlled with the -defaultRenderLevel configuration option.

Some built-in items are drawn differently depending on how much time is available to draw them, and how big the item appears on the screen. The two main examples are images and text. Images are drawn at user-specifiable resolutions at low levels of refinement, and at high-resolution at higher refinement levels. Text is drawn as hashmarks, at small sizes, and as horizontal lines at extremely small sizes.

In addition, facilities are provided so that user-defined items can be drawn with different levels of detail. The render and zooming callbacks can be used in combination with the getsize, and render commands to modify the way the item is drawn depending on the refinement level and size of the item.

See the above section on Region Management and Screen Updating.

Pad++ adjusts the frame rate during animations and zooming to maintain constant perceptual flow, independent of processor speed, scene complexity, or window size. For example, if a specific animation is specified to take 750 milliseconds, just enough animation frames are rendered so that the animation takes 750 milliseconds.

Whenever the system is doing a slow task, such as refining or animating, any event (such as a key-press or mouse-click), will interrupt the task and control will immediately be given back to the user. For example, pressing the space-bar during an animation will immediately bring you to the end of the animation. Panning during a refinement will immediately stop the refinement and go on with high-speed panning. Interruption can be turned off with the -interruptible configuration option.

While Pad++ is modeled after the Tk Canvas widget, there are several unique features of Pad++, in addition to the basic multiscale concept.

Portals are a special type of item in Pad++ that sit on the Pad++ surface with a view onto a different location. Because each portal has its own view, the surface might be visible at several locations, each at a different magnification, through various portals. In addition, portals can look onto surfaces of other Pad++ widgets. See the description of Portal Items in the reference manual, as well as the description of the bind command for more information about portals.

It is possible to attach event handlers to items on the Pad++ surface so that when a specific event (such as ButtonPress) reaches an item, that event handler fires, and an associated command is executed. This system operates much as it does with the Tk Canvas widget, but there are several significant additions. See the pad bind command for complete details, but the extensions fall into the following three categories:

In addition to the event bindings that every item may have, every Pad++ item can define Tcl scripts associated with it which will get evaluated at special times. There are four types of these callbacks:

A render callback script gets evaluated every time the item is rendered. See the -renderscript itemconfigure option for more detail.

A timer callback script gets evaluated at regular intervals, independent of whether the item is being rendered, or receiving events. See the -timerscript and -timerrate itemconfigure options for more detail.

A zooming callback script gets evaluated when an item gets rendered at a different size than its previous render - where the relevant size thresholds are definable. This is a simple way of making "semantically zoomable" items - that is, items that look different when the are rendered at different sizes. See the -zoomaction itemconfigure option for more detail.

A view change callback gets evaluated whenever the view onto the Pad++ surface changes (as a result of commands such as moveto, center, etc.) See the -viewscript itemconfigure option for more detail.

It is possible to add user-defined types and options to Pad++ entirely with Tcl scripts (i.e., no C/C++ code). This provides a mechanism to define new compound item types that are treated like first-class Pad++ items. That is, they can be created, configured, saved, etc. with the same commands you use to interact with built-in items, such as lines or text. These extensions are particularly well-suited for widgets, but can be used for anything. See the Application-Defined Item Types and Options section above for a detailed description.

Pad++ has several methods for producing animations. The moveto command animates the view of the surface to any new point in a specified time. Individual items can be animated with either render or timer callbacks. Finally, panning and zooming is animated under user-control, defined by scripts supplied with the PadDraw application.

All automatic animations use slow-in-slow-out motion. This means that the motion starts slowly, goes quicker in the middle, and ends slowly - resulting in smoother feeling animations. This does not affect the time the animation takes because time is effectively stolen from the middle to put at the ends. User-controlled animations are specified precisely by the user, and there is no distortion of the motion speed.

Pad++ Programmer's Guide - 20 JUN 1997

Copyright Computer Science Department, The University of New Mexico

Web Accessibility