Carbon Drawing Tips

This section includes some tips for improving the drawing performance of Carbon applications.

Draw Minimally

Poor drawing performance is often caused by an application drawing content unnecessarily. Whenever your application receives an event asking it to redraw content, it should pay attention to the drawing rectangle it receives and limit itself to this rectangle. For Carbon applications, you can get the current bounds from the attributes of the kEventWindowDrawContent event.

You can use the Quartz Debug tool to see where your application is drawing and to find areas where it is drawing content redundantly. For more information, see “Using Quartz Debug.”

Optimize Your Resize Code

Live window resizing tends to put a greater strain on your drawing code than any other update operation. During a few seconds, your drawing code might receive dozens of events to update large portions of your window content. If your drawing code is not fast enough to keep up with this onslaught of events, your application may seem visibly sluggish to the user.

If you know you are in the middle of a live resize operation, consider ways to simplify your redrawing code. Cache data whenever possible or include special cases in your drawing code that favor speed over precision.

For help on how to handle live resize updates for both Cocoa and Carbon applications, see “Carbon Live Window Resizing.”

Clean Up Your Drawing Code

Your application’s drawing code gets called frequently to make sure your interface is up-to-date. During a live resizing operation, the system may call your drawing routines many times a second to display uncovered regions of your window. Because they can be called frequently, your drawing routines should focus solely on drawing. They should not attempt to calculate data values or do anything that is not necessary for drawing content. For example, if you are developing a game, you should not use your drawing routine to perform collision detection. You should perform those calculations outside of your main drawing routines.

Coalesce View Updates

Whenever you render content, the system keeps track of the regions you modify and coalesces them into an update region to be flushed to the window buffer. If your drawing code updates a large area of the screen using several shorter drawing calls, you may want to notify the window server of the total update region in advance. Invalidating a larger region in advance removes the need to calculate this region with each successive rendering call.

Use the and HIViewSetNeedsDisplayInRegion, HIViewSetNeedsDisplay, HIViewSetNeedsDisplayInRect or HIViewSetNeedsDisplayInShape functions to invalidate window content whenever you can. Be careful not to coalesce your updates if the resulting region would contain unchanged content. For more information about using HIView functions, see HIView Programming Guide.

You can determine if you are redrawing unchanged content using the Quartz Debug application. See “Measuring Drawing Performance” for more information.

Use Asynchronous Window Dragging

Available in Mac OS X version 10.3 and later, applications have the option of supporting asynchronous window dragging. A new window attribute, kWindowAsyncDragAttribute, allows the window server to handle drag events without the involvement of your application. This implementation reduces the number of inter-process calls between your application and the window server and also lets the user drag windows even when your application is busy doing something else.

If you implement this feature, make sure to remove your existing code for handling window drag events. If you leave this code in place, window dragging may appear jumpy as both your application and the window server handle the drag events.

Adopt HIToolbox

If your application runs on Mac OS X version 10.2 and later, you should adopt the HIToolbox functions and data types for drawing your windows and controls. The HIToolbox provides a high-level, object-oriented approach to implementing your application’s user interface. The routines in this toolbox implement much more behavior and are tuned for performance better than the older QuickDraw, Window Manager, and Control Manager routines.

See the HIToolbox reference for more information.

Adopt HITheme APIs

If you are using the Appearance Manager for your drawing appearance primitives, you should adopt the HITheme routines introduced in Mac OS X version 10.3. The HITheme routines provide basically the same features as the older Appearance Manager but are more highly tuned for Mac OS X.

Hide Controls During Multi-State Changes

Whenever you change an attribute of a control, the system must redraw the control to reflect the change. If you make several adjustments to a control at one time, the system may redraw the control several times to reflect each minor change. Rather than waste time redrawing the control after every call, you should instead hide the control while changing its attributes. After you finish making your changes, show the control again to force a redraw event.

If you are using the HIToolbox routines, you can use the HIViewSetVisible function to hide or show views and controls in your windows. If you are using the Control Manager, use the SetControlVisibility function.

Use Tracking Regions

If your application tracks the mouse over particular regions of a window, make sure you use the Carbon Event Manager to set up tracking regions. Tracking regions based on the Carbon Event Manager do not poll the system to determine the current mouse location. Instead, the system notifies your application when the mouse enters or exits a particular region.

To create a mouse tracking region, call the CreateMouseTrackingRegion function. For more information, see the Carbon Event Manager reference.

< Previous PageNext Page >

Hide TOC

Did this document help you?
Yes: Tell us what works for you. It’s good, but: Report typos, inaccuracies, and so forth. It wasn’t helpful: Tell us what would have helped.