Re: Coalesced updates and refresh rate
Re: Coalesced updates and refresh rate
- Subject: Re: Coalesced updates and refresh rate
- From: Wolfgang Kundrus <email@hidden>
- Date: Wed, 15 Jun 2011 15:42:05 +0200
Thanks for taking the time to respond. I am certainly not a newbie, being
a Mac programmer since 1987 having brought three major applications with
millions of customers to market that all run cross platform.
That aside, I am trying to understand, why Cocoa does not flush the
graphics, if there has been drawn something to the window with the a method
that works well otherwise. I understand coalescing updates and I want to
stay away from CGContextFlush as this would cause the application to block,
if another flush has to happen.
We do use the invalidate/draw wherever appropriate. In this specific base,
invalidate does not help, because it is not a simple redraw operation, but
rather moving an object by a few pixel without tearing. The other case where
we use direct drawing is the potentially hundreds of meter object that need
to be updated in a very specific way at a rate that is perceived as fluent.
All the best
Wolfgang
2011/6/15 Graham Cox <email@hidden>
>
> On 15/06/2011, at 10:30 PM, Wolfgang Kundrus wrote:
>
> > We have to update a lot of small onscreen objects and performance is way
> better, when we travers them outside the Cocoa view tree. If we would use
> invalidating, we would have to go thru our complete view tree and check for
> overlaps with the update rect.
> >
>
> Does each object have its own view? If so, then that's definitely not a
> good idea. If not, then there really shouldn't be a problem - checking for
> overlap with the update rect is a simple matter of a) invalidating the
> update rect(s) and b) at DRAW time, call [NSView needsToDrawRect:] to test
> for overlap. Invariably it is drawing that dominates performance for this
> type of scenario, so a simple YES/NO test of this type is well worthwhile
> and is very fast.
>
> If you have, say < 1000 objects that need updating, a linear list of these
> will probably suffice on a modern machine. If you have more, a spatial
> hashing scheme such as BSP can give useful improvements, and NSView has the
> method -getRectsBeingDrawn:count: that can be used as an input to a spatial
> hash. I use this technique in DrawKit, and unless the objects are especially
> complex in what they draw, it's easy to achieve a refresh of many thousands
> of objects within 16mS (which equates to 60fps).
>
> If you have found performance to be bad using Cocoa's drawing mechanism, I
> suggest you must have overlooked something or made a newbie error such as 1
> view per object, because in my experience it is adequate in terms of
> scheduling the updates and testing for objects needing to be drawn. Cocoa
> caps the framerate at 60fps anyway so you will never do better than that,
> but it sounds like you're way off base, so there's a long way to go before
> giving up on the standard mechanism.
>
> --Graham
>
>
>
>
--
Managing Director
PreSonus Software Limited
Bramfelder Straße 76
22305 Hamburg, Germany
Phone: +49 (0) 40 - 69 70 49 32
Direct line: +49 (0) 40 - 69 70 52 45
Fax: +49 (0) 40 - 69 70 49 33
Web: www.presonussoftware.com
_______________________________________________
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