IKImageBrowser performance issues

  • I'm having severe performance issues with the IKImageBrowser classes.
    I'm loading groups of around 100 images of decent resolution (one
    example is a group of 512x512 icons.) The rest of my app is based on
    CoreAnimation, and as soon as I start loading a new batch of images
    into the view, my CoreAnimation starts to stutter.

    I'm aware that loading large batches of images is resource itensive,
    but I'm running on a dual core system with nothing else intensive
    running in the background. I would assume my IKImageBrowser image
    loads would be farmed to a different core than my CoreAnimation code.

    Do I have any means of regulating IKImageBrowser*s CPU use? It's
    hogging the CPU in my app for a solid 5-10 seconds when I switch the
    items in the view, and I'm not sure the user will understand the
    reason for the CPU hit given that the visible images in the view will
    already be loaded.

    Sent from my iPhone
  • On Nov 25, 2007, at 5:19 PM, Colin Cornaby wrote:

    > Do I have any means of regulating IKImageBrowser*s CPU use? It's
    > hogging the CPU in my app for a solid 5-10 seconds when I switch the
    > items in the view, and I'm not sure the user will understand the
    > reason for the CPU hit given that the visible images in the view
    > will already be loaded.

    File a bug report with Apple. I'm not sure why it's loading
    "invisible" images at all (are you sure that's what's going on?), but
    it seems reasonable to expect that any such activity should be given a
    lower priority.

    j o a r
  • Sorry for the somewhat confusing email, the iPhone is not the ideal
    platform for typing these sorts of things. :)

    Basically what happens is I have a drop down menu to select groups of
    images to display within the browser view. When the group is switched
    out, I pull a different batch of items from a backing CoreData
    database that contains URL's to images. I then tell the image browser
    view to reload.

    After I switch groups, I can watch my app's CPU usage stay extremely
    high in process viewer, and graphics performance in other parts of my
    app declines rapidly. The image items in the browser view's currently
    viewed bounds are all loaded and visible. During this period of high
    cpu usage I scroll down and quickly run into "unloaded" images, which
    are represented by whatever the placeholder image is that Apple uses
    to represent unloaded items. The items are quickly filled in by the
    browser view.

    If I don't scroll down, and I just wait for my CPU usage to hit 0
    again, I can scroll through the browser view and all my images seem to
    be already loaded. This is what led me to believe that my image
    browser was preloaded all the images currently being vended by the
    datasource, not just the currently visible ones in the data browser.
    I'm sure some debugging in the data source for my browser would
    confirm that.

    I just find it odd that with IKImageBrowserView being so multithreaded
    that the browser item loading isn't being handled by a second core,
    leaving the first core free to continue maintaining the rest of my app.

    On Nov 25, 2007, at 9:22 PM, j o a r wrote:

    >
    > On Nov 25, 2007, at 5:19 PM, Colin Cornaby wrote:
    >
    >> Do I have any means of regulating IKImageBrowser*s CPU use? It's
    >> hogging the CPU in my app for a solid 5-10 seconds when I switch
    >> the items in the view, and I'm not sure the user will understand
    >> the reason for the CPU hit given that the visible images in the
    >> view will already be loaded.
    >
    >
    > File a bug report with Apple. I'm not sure why it's loading
    > "invisible" images at all (are you sure that's what's going on?),
    > but it seems reasonable to expect that any such activity should be
    > given a lower priority.
    >
    > j o a r
    >
    >
  • The behavior of the image browser is the following:
    When all the visible images are imported (ie. the placeholders are
    replaced by the thumbnail), the browser starts to prefetch some images
    in the neighborhood of the visible area.
    This prefetching is asynchronous (in a secondary thread) and with a
    low priority (except if you use the NSImage representation because
    NSImages are not 100% thread safe and so its "decompression" is always
    performed on the main thread).
    Which representation are you using ?

    > From: Colin Cornaby <colin.cornaby...>
    > Date: 26 novembre 2007 09:26:28 HNEC
    > To: j o a r <joar...>
    > Cc: <cocoa-dev...>
    > Subject: Re: IKImageBrowser performance issues
    >
    > Sorry for the somewhat confusing email, the iPhone is not the ideal
    > platform for typing these sorts of things. :)
    >
    > Basically what happens is I have a drop down menu to select groups
    > of images to display within the browser view. When the group is
    > switched out, I pull a different batch of items from a backing
    > CoreData database that contains URL's to images. I then tell the
    > image browser view to reload.
    >
    > After I switch groups, I can watch my app's CPU usage stay extremely
    > high in process viewer, and graphics performance in other parts of
    > my app declines rapidly. The image items in the browser view's
    > currently viewed bounds are all loaded and visible. During this
    > period of high cpu usage I scroll down and quickly run into
    > "unloaded" images, which are represented by whatever the placeholder
    > image is that Apple uses to represent unloaded items. The items are
    > quickly filled in by the browser view.
    >
    > If I don't scroll down, and I just wait for my CPU usage to hit 0
    > again, I can scroll through the browser view and all my images seem
    > to be already loaded. This is what led me to believe that my image
    > browser was preloaded all the images currently being vended by the
    > datasource, not just the currently visible ones in the data browser.
    > I'm sure some debugging in the data source for my browser would
    > confirm that.
    >
    > I just find it odd that with IKImageBrowserView being so
    > multithreaded that the browser item loading isn't being handled by a
    > second core, leaving the first core free to continue maintaining the
    > rest of my app.
    >
    > On Nov 25, 2007, at 9:22 PM, j o a r wrote:
    >
    >>
    >> On Nov 25, 2007, at 5:19 PM, Colin Cornaby wrote:
    >>
    >>> Do I have any means of regulating IKImageBrowser*s CPU use? It's
    >>> hogging the CPU in my app for a solid 5-10 seconds when I switch
    >>> the items in the view, and I'm not sure the user will understand
    >>> the reason for the CPU hit given that the visible images in the
    >>> view will already be loaded.
    >>
    >>
    >> File a bug report with Apple. I'm not sure why it's loading
    >> "invisible" images at all (are you sure that's what's going on?),
    >> but it seems reasonable to expect that any such activity should be
    >> given a lower priority.
    >>
    >> j o a r
    >>
    >>
previous month november 2007 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    
Go to today