The live resizing of windows is one place where users notice poor performance. When done right, resizing a window should feel smooth and go unnoticed by the user. When done wrong, window resizing can feel choppy and sluggish.
The key to optimizing live resize code is to draw as little as possible while still maintaining an acceptable look for your window. This usually means drawing only the L-shaped region exposed by resizing plus a few controls such as scrollbars and custom widgets. However, some applications may need to draw more content. For example, an application may need to do more redrawing if it dynamically reflows its window content based on the window width and height.
The best way to get good performance during live resize is to draw only the portions of the window that need to be redrawn. This is usually the newly exposed region of the window plus any areas that dynamically reflow their content based on the window size. The Carbon Window Manager passes the rectangles of the previous and the next window size in the kEventParamPreviousBounds
and kEventParamCurrentBounds
parameters of the kEventWindowBoundsChanging
event. You can take the difference of these two rectangles to obtain a region representing the space to update.
Clients of the Data Browser control should be sure to set the clip region to the newly-exposed region before asking the Data Browser to draw during live resize This allows the Data Browser to only draw cells that are within the newly-exposed region.
© 2003, 2006 Apple Computer, Inc. All Rights Reserved. (Last updated: 2006-04-04)