Question

That is, if

[self setNeedsDisplayInRect:rect];

is called, and rect is very carefully calculated for the region that needs to be redrawn, but if our drawRect code doesn’t care about rect and draw everything anyway, can the iOS system still somehow improve the drawing speed? (or possibly improve very little?) This question probably requires somebody who is very familiar with UIKit/CoreGraphics.

Answer 1

There are a few ways the answer could be yes:

1. You can clip to the rectangle, in which case anything outside it won’t be painted, even if you draw in it. Drawing outside the rectangle won’t be free, but it will be cheaper. iOS can’t do this for you because you might deliberately ignore the rect, or use the rect but also draw something else elsewhere in your bounds unconditionally. (Though that other thing should probably be another view.)
2. Even if your current drawRect: doesn’t use the rectangle, you might go back to that code later to optimize it. As you’re probably aware, one very good way to do that—if it’s at all possible—is to use the rectangle to decide what you draw. Even if you’re not doing that now, you may do it in the future, and specifying changed rects now means that many fewer things to change then.
3. A corollary to #3 is that even if what you’re drawing now can’t be so optimized, you may decide in a future major version to completely change what the view draws to something that can. Again, specifying changed rects now means that many fewer things to do in the future.
4. Subviews. If your view doesn’t actually draw some of the things that the user sees in it, but rather delegates (not in the Cocoa/Cocoa Touch sense) those things to subviews, then you might override setNeedsDisplayInRect: to send setNeedsDisplay: messages to subviews—and only the subviews whose frames intersect the rect—before calling super. (And UIView’s implementation might already do this. You should test it.)