On 20/10/2009, at 8:58 AM, Ben Haller wrote:
I think the problem is deeper (based upon what flashes under Quartz Debug): I think the dirty rects are actually getting consolidated such that NSTableView no longer has the information it needs to do minimal drawing. I could be mistaken about that, though, if the flashes in Quartz Debug show only the area that Quartz is choosing to blit over, and not necessarily the area that was considered dirty and redrawn. (i.e. if it brings over merged areas for efficiency, for some reason; but that seems unlikely...)
I think what you're observing is right. If you invalidate two disjoint rects in a view, while Quartz keeps track of those separate areas, its overall union is calculated and passed to any -drawRect: methods (intersected with that view's frame) that get called as a result. Many simple views will not bother to break that down. If the disjoint areas are far apart, that can be a considerable area. (As an aside, I think Cocoa does miss an efficiency trick there, because it could intersect each view's frame with the original dirty rect list for the window, then union the result to pass to -drawRect:, rather than with the union of that list as it appears to do - i.e. if it did intersect + union it would come up with smaller areas for each view than union + intersect, but there may be other factors such as backward compatibility and speed of calculating these rects to consider).
I suspect its likely that NSTableView is just taking its -drawRect: parameter as what it needs to update and doing that, rather than further examining the individual dirty rects. I think the ability to maintain and test the individual dirty rects was only added in 10.3 or so, possibly earlier, but certainly wasn't inherited from OpenStep. The flashes in Quartz Debug may also be representing areas that other parts of the view (the background, say) are responding to which is masking what NSTableView is updating. I'm not sure if QD has any way to separate out the two (it can't know how a specific view is responding to -drawRect:, whether it is further testing against the dirty rects) so it might not be showing you the true picture.
However, maybe you shouldn't get too hung up on this. If your own custom views do complex drawing, then using -needsToDrawRect: and/or - getRectsBeingDrawn:count: are well worth using and you can trust them to do the right thing, regardless of what QD shows is the update rect. There's nothing to lose by using these methods really, but equally there may be nothing to gain either. You might not be able to do much about NSTableView whatever it's doing internally. Does profiling indicate that drawing updates are too slow?
--Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
