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: Ben Haller <email@hidden>
- Date: Mon, 19 Oct 2009 21:02:15 -0400
On 19-Oct-09, at 6:53 PM, Andy Lee wrote:
On Monday, October 19, 2009, at 05:58PM, "Ben Haller" <email@hidden
> 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.
To test this theory, might it help to use a subclass of NSTableView
whose drawRect: method prints the rectangle passed to it, and see
what happens when your graph views do and do not do any drawing?
And maybe the result of getRectsBeingDrawn:count: as well?
Just did this. The results are interesting. Two points of note:
- my tableview does seem to be getting passed a nicely limited dirty
rect, even though Quartz Debug flashes a much larger area. So
apparently flashes in Quartz Debug are only indicative of what Quartz
is choosing to blit over to the screen, not what is actually getting
updated. If so, it would be useful to have a new checkbox in Quartz
Debug that flashed only the areas actually getting marked as dirty, I
think, so that one could check one's minimal-redraw correctness. I
logged 7317630 on this.
- there do seem to be some weirdnesses in the dirty rect accumulation
code. For example, when I call -getRectsBeingDrawn:count: and log the
results, I typically see something like this:
count == 2
rects[0] == {{47, 12}, {45, 215}}
rects[1] == {{47, 0}, {45, 12}}
So abutting rects of the same width are not getting merged
together. Oddly, the dividing line between these rects is not at a
line boundary in my tableView; a bunch of lines get accumulated
together into the tall rect, and then the topmost line gets split
between the tall rect and the little rect. I have no theory as to why
this would be.
As for NSTableView, it does appear to be doing minimal drawing. So
I guess all the string-drawing overhead I see in Sampler is just from
the single column that is updating, which is unfortunate since it
means I have no room for optimization. I never imagined it would take
so much time just to draw the one column I dirtied.
So, sorry for the false alarm. The main take-home point I get out
of all this is that Quartz Debug flashes the areas being blitted over,
which are not the same as the areas marked dirty or the areas
requested to be redrawn!
Ben Haller
Stick Software
_______________________________________________
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