Re: Leak when "drawing too fast"

2013-07-30 Thread Andreas Mayer
Am 26.07.2013 um 12:41 schrieb Uli Kusterer : >> Since I can use Core Animation, that is obviously the better solution. It >> also makes my application look less power hungry - because now it is the >> WindowServer doing the drawing and eating cpu. ;) > > Not sure I follow your reasoning here.

Re: Leak when "drawing too fast"

2013-07-30 Thread Andreas Mayer
Am 26.07.2013 um 12:41 schrieb Uli Kusterer : > No no no! Don’t do both at the same time! The display link callback is called > exactly when you’re supposed to draw! Hm. So i remove drawRect: and call that in the callback instead? > If you call setNeedsDisplay: there, you’ll be waiting until

Re: Leak when "drawing too fast"

2013-07-26 Thread Uli Kusterer
On Jul 26, 2013, at 5:11 PM, Kyle Sluder wrote: > On Fri, Jul 26, 2013, at 03:41 AM, Uli Kusterer wrote: >> On Jul 25, 2013, at 20:26, Andreas Mayer wrote: >>> Am 25.07.2013 um 19:36 schrieb Uli Kusterer : >>> Have you considered using a display link callback instead of a timer? >>> >>>

Re: Leak when "drawing too fast"

2013-07-26 Thread Kyle Sluder
On Fri, Jul 26, 2013, at 03:41 AM, Uli Kusterer wrote: > On Jul 25, 2013, at 20:26, Andreas Mayer wrote: > > Am 25.07.2013 um 19:36 schrieb Uli Kusterer : > > > >> Have you considered using a display link callback instead of a timer? > > > > Yes. Moving to the display link callback was when I no

Re: Leak when "drawing too fast"

2013-07-26 Thread Uli Kusterer
On Jul 25, 2013, at 20:26, Andreas Mayer wrote: > Am 25.07.2013 um 19:36 schrieb Uli Kusterer : > >> Have you considered using a display link callback instead of a timer? > > Yes. Moving to the display link callback was when I noticed the issue in the > first place. Usually, when drawing from

Re: Leak when "drawing too fast"

2013-07-25 Thread Andreas Mayer
Am 25.07.2013 um 19:36 schrieb Uli Kusterer : > Have you considered using a display link callback instead of a timer? Yes. Moving to the display link callback was when I noticed the issue in the first place. Calling -setNeedsDisplay: in the display link callback is too fast. It gives smooth a

Re: Leak when "drawing too fast"

2013-07-25 Thread Uli Kusterer
On Jul 25, 2013, at 7:09 PM, Andreas Mayer wrote: > I tried different ways to limit the drawing frequency but ended up with > either timers piling up or jittery animation. Have you considered using a display link callback instead of a timer? That should call you just in time. Or CALayer, which

Re: Leak when "drawing too fast"

2013-07-25 Thread Andreas Mayer
A followup: Am 10.07.2013 um 02:10 schrieb Uli Kusterer : > I don’t think the timers leak. Instead, I think they probably just queue up > on the event loop because their fire interval is greater than that at which > you add new timers by calling setNeedsDisplay. Could that be it? You are right

Re: Leak when "drawing too fast"

2013-07-09 Thread Uli Kusterer
On Jul 8, 2013, at 20:28, Andreas Mayer wrote: > It seems like when I call -setNeedsDisplay:YES the system is spawning a timer > to do something later on and when those calls come in too fast, that timer is > leaked. > > Any idea what I could do about that? > (I tried calling -setNeedsDisplay:Y

Leak when "drawing too fast"

2013-07-08 Thread Andreas Mayer
This is on OS X 10.8.4. I'm trying to animate something and draw as smoothly as possible. While trying to utilize a display link callback I noticed a memory leak in my application. After some experimentation I found out that this is not directly linked to the callback but instead also happens w