Re: Dirty rects getting merged together makes for inefficient drawing
Re: Dirty rects getting merged together makes for inefficient drawing
- Subject: Re: Dirty rects getting merged together makes for inefficient drawing
- From: Graham Cox <email@hidden>
- Date: Tue, 20 Oct 2009 11:28:30 +1100
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 (email@hidden)
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:
This email sent to email@hidden