• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Optimizing NSRectFill
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optimizing NSRectFill


  • Subject: Re: Optimizing NSRectFill
  • From: Jean-Daniel Dupas <email@hidden>
  • Date: Sat, 20 Dec 2008 22:58:15 +0100


Le 20 déc. 08 à 22:47, Jean-Daniel Dupas a écrit :


Le 20 déc. 08 à 21:14, Michael Ash a écrit :

On Sat, Dec 20, 2008 at 1:51 PM, Kyle Sluder <email@hidden> wrote:
On Sat, Dec 20, 2008 at 12:18 PM, Michael Ash <email@hidden> wrote:
A simple way to do this is to avoid calling setNeedsDisplay: (or its
friends) directly from your event handler. Instead start a timer with
some suitably small interval, and set a flag. If the flag is already
set, don't start the timer, it's already been started. When the timer
fires, invalidate the view and clear the flag.

Alright, perhaps I don't completely understand how the drawing model
works at a low enough level, but why would this be helpful? Doesn't
AppKit just coalesce updates received by -setNeedsDisplayInRect: until
Quartz has finished pushing pixels? So if you are accumulating dirty
rects in your event handler, your drawing should still be limited to
min(as fast as possible, 60hz).


Or am I thinking of the Quartz GL pipeline?

My understanding is that everything is sychronous. So if you call setNeedsDisplay: in your event handler, then the sequence will always look like this:

event handler
 mark view invalid
check for invalidated views
 redraw invalidated view
 flush results to screen
event handler
 mark view invalid
check for invalidated views
 redraw invalidated view
 flush results to screen

And so forth. I could be wrong about this, and if anyone knows better
please pipe up!

I did a quick test.
I have a 1ms timer which just do -setNeedDisplay: on a small view.
And the result is that my timer callback is called 60 times per seconds.
If I remove the seetNeedDisplay: call, it is called 1000 times (as expected).


So I think that you're right (and that everything is synchronous) but I also think that the 'flush results to screen' blocks until the screen is ready and so limit the number of redraw to the refresh rate of the screen.
If this is effectively the case, your timer trick will not be very helpful.



How, and I found that too:

http://developer.apple.com/technotes/tn2005/tn2133.html






_______________________________________________

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


References: 
 >Optimizing NSRectFill (From: "Oleg Krupnov" <email@hidden>)
 >Re: Optimizing NSRectFill (From: Peter Ammon <email@hidden>)
 >Re: Optimizing NSRectFill (From: "Oleg Krupnov" <email@hidden>)
 >Re: Optimizing NSRectFill (From: "Michael Ash" <email@hidden>)
 >Re: Optimizing NSRectFill (From: "Kyle Sluder" <email@hidden>)
 >Re: Optimizing NSRectFill (From: "Michael Ash" <email@hidden>)
 >Re: Optimizing NSRectFill (From: Jean-Daniel Dupas <email@hidden>)

  • Prev by Date: Re: Optimizing NSRectFill
  • Next by Date: Re: Text track in QTMovie
  • Previous by thread: Re: Optimizing NSRectFill
  • Next by thread: Re: Optimizing NSRectFill
  • Index(es):
    • Date
    • Thread