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: Andy Lee <email@hidden>
- Date: Mon, 19 Oct 2009 22:40:03 -0400
Come to think of it, another experiment would have been to add logging
to the cells used for the other table columns, to see if their drawing
code was actually being called.q
Sorry if I missed this, but is the string-drawing overhead noticeable
to the user? If so, and it's because you're redrawing very
frequently, maybe you could throttle redrawing to, say, 2-4 times per
second. There's something called coalesced updates that might help.
Does the table column's cell have to do much work to get the string it
needs to draw (a gross example would be querying a database)? Maybe
caching would help.
I don't know how much overhead is in cell drawing, but maybe you could
write your own cell class that doesn't, for example, check whether the
string needs to be truncated.
There's a section in the docs on optimizing drawing. I must admit I
haven't read it, but maybe it contains something that would help in
your case?
Sorry for all the might's and maybe's --I'm hoping one of my stabs in
the dark will help.
--Andy
On Oct 19, 2009, at 9:02 PM, Ben Haller <email@hidden>
wrote:
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