Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: who's responsible for erasing?

On Friday, May 30, 2003, at 10:40 AM, Joseph J. Strout wrote:

Thanks mainly to Eric's persistence and patience, we finally have a custom control that can draw itself in response to its part of the window being invalidated.

Yay! Congratulations.

However, it never erases, so (since it's drawing translucent content), we get just one layer of drawing on top of another. I've read over the documentation on kEventWindowUpdate and kEventDrawContent -- neither of which we're overriding at the moment (i.e., we use the standard handlers) -- and the docs don't say that either of these erase the invalidated region. That matches my observations.

That's correct.

But the docs on kEventControlDraw don't say that you should erase before drawing, nor does the sample code in the docs do so. And I don't think I would expect erasing at this point to work, in cases where you have overlapping or embedded controls.

So, I'm asking for a recommendation: at what point should I erase the invalidated area, so that the new content can be drawn on the correct background? Should I do this when I call InvalWindowRect? Or should I override
kEventWindowUpdate to get and erase the update region, before doing the rest of the drawing (in particular calling DrawControls)?

Or do my observations indicate that (again) something in our pane library is interfering with the normal behavior of these carbon > events?

Well, first here's a summary of how erasing has traditionally worked (let's assume unbuffered windows on Mac OS 9 for now):

- when the window is first shown, the Window Manager erases the background, using the white (pre-colorQD), the 'wctb' content color (color QD), or the window's theme background, content color, or content pattern (Appearance Manager 1.0 and later).

- when a portion of a window is exposed because you move aside another window that's in front of the exposed window, the Window Manager erases the exposed area using the same rules as above.

- InvalWindow[Rect/Region] do not erase

- the traditional behavior of the standard Control Manager controls has been to always erase the control's bounds before drawing. Note, however, that this is not required or enforced by the Control Manager; it's just the traditional behavior, and apps assume it.

This is basically the same on X, except that since windows are buffered, if you move aside a window, the windows underneath it aren't erased and don't get update events; they just redraw from their back buffers.

There is one huge problem with this traditional model: that the controls erase their bounds before drawing. This effectively prevents you from having overlapping controls in the traditional Control Manager model, because as each control draws it will erase portions of other controls that it overlaps.

On Mac OS X, this problem is solved by compositing mode in 10.2 and later. In compositing mode, the standard controls do _not_ erase behind themselves; instead, the Control Manager ensures that when a given region of the window needs to be redrawn, every control that intersects that area is redrawn, from back to front, which lets the window content view draw first and provide your initial white background on which everything else is built.

So:

In your case, you are probably not using compositing mode. This usually means that you should erase inside your custom control; this becomes especially important if you're embedding controls inside tab panes, because the tab pane pattern origin can be different from the pattern origin for the window background as a whole, so you can only get the right pattern alignment if you erase the area inside the tab pane separately from the area outside of the tab pane.

However, if you have overlapping controls, this will likely be a problem. Ideally you would use compositing mode, and not erase inside the control. However, if you're trying to run this on pre-10.2, compositing mode won't be available. You might try erasing at the time that you invalidate the window, and not erasing from the custom controls; this might work, I'm not sure.

-eric
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.
References: 
 >who's responsible for erasing? (From: "Joseph J. Strout" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.