Core Image performance

  • I've got an app that's doing a full screen transition between images
    via a Core Image Filter, and I'm surprised to find that the
    performance is pretty bad. All I've heard about CI seemed to say that
    it took care of the hooks to the graphics hardware automatically. I
    guess I'm wrong.

    My basic approach is to put up a full screen borderless window with a
    custom view. The custom view uses the CIDissolveTransition, and has
    an NSTimer which repeatedly triggers a method that bumps the time
    value on the transition along.

    It's nice and smooth at maybe half screen, but any bigger and it just
    can't keep up.

    Could it be that all the Cocoa stuff involved with the NSTimer is
    really inefficient? Is it a bad idea to try and stick it in a window
    like that? I need it to remain a basic cocoa window because I've got
    to stick another window on top of it with various controls.

    Any advice would be great. If there's a better place to get help on
    this, that would be good to know, too. I hesitate to go to the Quartz
    dev list, since my feeling is that conversation would quickly leave
    the realm of Cocoa, where I'd like to stay, if possible.

    thanks

    -e
  • You might want to look at CVDisplayLink() which I've found very CPU
    non-intensive and quite lovely all around. It only asks you to
    render/draw when the display is being refreshed (or 60 FPS for LCDs).
    It's great at limiting CPU usage.

    Ack, at 10/26/06, Eric Blanpied said:

    > I've got an app that's doing a full screen transition between images
    > via a Core Image Filter, and I'm surprised to find that the
    > performance is pretty bad. All I've heard about CI seemed to say
    > that it took care of the hooks to the graphics hardware
    > automatically. I guess I'm wrong.
    >
    > My basic approach is to put up a full screen borderless window with
    > a custom view. The custom view uses the CIDissolveTransition, and
    > has an NSTimer which repeatedly triggers a method that bumps the
    > time value on the transition along.
    >
    > It's nice and smooth at maybe half screen, but any bigger and it
    > just can't keep up.
    >
    > Could it be that all the Cocoa stuff involved with the NSTimer is
    > really inefficient? Is it a bad idea to try and stick it in a window
    > like that? I need it to remain a basic cocoa window because I've got
    > to stick another window on top of it with various controls.
    >
    > Any advice would be great. If there's a better place to get help on
    > this, that would be good to know, too. I hesitate to go to the
    > Quartz dev list, since my feeling is that conversation would quickly
    > leave the realm of Cocoa, where I'd like to stay, if possible.

    --

    Sincerely,
    Rosyna Keller
    Technical Support/Carbon troll/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People

    It's either this, or imagining Phil Schiller in a thong.
  • So this would be instead of doing it on drawRect:?

    -e

    On Oct 26, 2006, at 12:38 pm, Rosyna wrote:

    > You might want to look at CVDisplayLink() which I've found very CPU
    > non-intensive and quite lovely all around. It only asks you to
    > render/draw when the display is being refreshed (or 60 FPS for
    > LCDs). It's great at limiting CPU usage.
    >
    > Ack, at 10/26/06, Eric Blanpied said:
    >
    >> I've got an app that's doing a full screen transition between
    >> images via a Core Image Filter, and I'm surprised to find that the
    >> performance is pretty bad. All I've heard about CI seemed to say
    >> that it took care of the hooks to the graphics hardware
    >> automatically. I guess I'm wrong.
    >>
    >> My basic approach is to put up a full screen borderless window
    >> with a custom view. The custom view uses the CIDissolveTransition,
    >> and has an NSTimer which repeatedly triggers a method that bumps
    >> the time value on the transition along.
    >>
    >> It's nice and smooth at maybe half screen, but any bigger and it
    >> just can't keep up.
    >>
    >> Could it be that all the Cocoa stuff involved with the NSTimer is
    >> really inefficient? Is it a bad idea to try and stick it in a
    >> window like that? I need it to remain a basic cocoa window because
    >> I've got to stick another window on top of it with various controls.
    >>
    >> Any advice would be great. If there's a better place to get help
    >> on this, that would be good to know, too. I hesitate to go to the
    >> Quartz dev list, since my feeling is that conversation would
    >> quickly leave the realm of Cocoa, where I'd like to stay, if
    >> possible.
    >
    > --
    >
    >
    > Sincerely,
    > Rosyna Keller
    > Technical Support/Carbon troll/Always needs a hug
    >
    > Unsanity: Unsane Tools for Insanely Great People
    >
    > It's either this, or imagining Phil Schiller in a thong.
  • Correct.

    Ack, at 10/26/06, Eric Blanpied said:

    > So this would be instead of doing it on drawRect:?
    >
    >
    > On Oct 26, 2006, at 12:38 pm, Rosyna wrote:
    >
    >> You might want to look at CVDisplayLink() which I've found very CPU
    >> non-intensive and quite lovely all around. It only asks you to
    >> render/draw when the display is being refreshed (or 60 FPS for
    >> LCDs). It's great at limiting CPU usage.

    --

    Sincerely,
    Rosyna Keller
    Technical Support/Carbon troll/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People

    It's either this, or imagining Phil Schiller in a thong.
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today