Re: Optimizing NSRectFill
Re: Optimizing NSRectFill
- Subject: Re: Optimizing NSRectFill
- From: Peter Ammon <email@hidden>
- Date: Mon, 22 Dec 2008 13:18:42 -0800
setNeedsDisplay: and setNeedsDisplayInRect: do not integrate with
coalesced updates as well as they might. If you call setNeedsDisplay:
faster than 60 times per second, then you will encounter the problem
described in the technote.
Did turning off coalesced updates in Quartz Debug help? If so, do not
call setNeedsDisplay: or setNeedsDisplayInRect: for every event, but
only if the time since the previous call is at least 1/60th of a
second. This should give you the responsiveness you expect.
On Dec 20, 2008, at 6:22 AM, Oleg Krupnov wrote:
Here is how I arrived at the conclusion that NSRectFill is the
bottleneck. (I cannot show the code because it's spread over objects).
The slowness of redraw is only noticeable when I drag the mouse, e.g.
to resize an object in the custom view. I see that update of the
resized object is always late after the actual position of the mouse
pointer, and the latency is sometimes pretty great to not be excused.
Especially when the size of the rectangle to be updated is large.
My custom view supports zooming, so I call NSRectFill after setting an
NSAffineTransform. Larger zooms, as I said, seem to cause greater
latency. Sometimes I also use clipping ([NSBezierPath addClip]) before
calling NSRectFill.
I never call -[NSView displayIfNeeded] or use other ways of forcing
the view to update itself. I always rely on -[NSView
setNeedsDisplayInRect:] to invalidate the rectangle(s) that need to be
updated and then wait until the next refresh. What is true, that
-[NSView setNeedsDisplayInRect:] are often called multiple times for
the same rectangles, but I don't think it matters.
I run my app with the Shark tool and drag the mouse to resize an
object, to and fro, for few seconds, then check the sample. It always
shows that 20-30% of time is taken by the NSRectFill function, which
is called only once to simply draw the background of the view with
solid white! This is ridiculous. I tried to put an NSLog near the
NSRectFill call to check if it is called extra times, but it seems
that it is being called exactly one time per single mouse drag
message. When I comment out the call to NSRectFill, then the refresh
becomes noticeably smoother, and the Shark gives leadership to other
bottlenecks, in my case the NSBezierPath stroke and fill messages, for
the objects drawn in the view.
Any ideas?
On Sat, Dec 20, 2008 at 1:45 AM, Peter Ammon <email@hidden> wrote:
On Dec 19, 2008, at 7:37 AM, Oleg Krupnov wrote:
I'm developing a custom view and noticed that drawRect is becoming
increasingly slow. The Shark has pointed out that the bottleneck is
the NSRectFill function (that calls CGContextFillRect under the
hood)
that I use to draw the background of the view.
A common cause of apparently excessive time in graphics related ops
is that
you are running afoul of coalesced updates by attempting to refresh
faster
than 60 times a second.
See
http://developer.apple.com/documentation/Performance/Conceptual/Drawing/Articles/FlushingContent.html
.
Try disabling coalesced updates in Quartz Debug and see if it
speeds up
your drawing. If so, ensure your app does not refresh faster than
60 Hz.
-Peter
_______________________________________________
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