• 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: IKImageBrowserView image quality changing with redraw
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKImageBrowserView image quality changing with redraw


  • Subject: Re: IKImageBrowserView image quality changing with redraw
  • From: Thomas Goossens <email@hidden>
  • Date: Tue, 08 Dec 2009 14:59:57 +0100

Hi Adam,

Is this on Leopard or Snowleopard ?
I just tried to load images from /System/Library/Desktop Pictures in an IKImageBrowserView using the NSImage representation. They appears just fine for me (SnowLeopard).

> [Side note: I've seen reference to the prefetching behavior
> of IKImageBrowserView is particularly gnarly for NSImages as all the preload
> must be done on main thread since NSImage is not thread safe. ?]

This is true on Leopard, but not on SnowLeopard.

> With this in
> mind, what's the preferred type for IKImageBrowserItem backings

If you images exists on the filesystem, it is preferable to use a path or url based representation.
Otherwise, there is no preferred representation.

-- Thomas


On Dec 8, 2009, at 1:01 AM, Adam Berger wrote:

> I'm trying to move from a custom view to an IKImageBrowserView in a project,
> and running into a somewhat odd problem. Context: my IKImageBrowserItems are
> IKImageBrowserNSImageRepresentationType, backed by a relatively
> large (~600x800) NSImage.
>
> When first drawn, at any scale factor, this looks great. However, as soon as
> a redraw (not a reload!) occurs, the quality goes to hell. For example,
> clicking in the browserview will cause this problem instantly. It's as if
> it's deciding all of a sudden to fall back to a cached image of much lower
> quality. Scrolling seems not to trigger a redraw of this type; so if a large
> view containing as-first-drawn high quality images is clicked, only the
> currently visible thumbnails will get degraded, and scrolling can then
> present a mix of degraded and full-quality images.
>
> Needless to say, this huge a reduction in image quality is not acceptable.
> How can this be prevented?
>
> [Side note: I've seen reference to the prefetching behavior
> of IKImageBrowserView is particularly gnarly for NSImages as all the preload
> must be done on main thread since NSImage is not thread safe. With this in
> mind, what's the preferred type for IKImageBrowserItem backings?]
>
> Adam
> _______________________________________________
>
> 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

_______________________________________________

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

  • Follow-Ups:
    • Re: IKImageBrowserView image quality changing with redraw
      • From: Adam Berger <email@hidden>
References: 
 >IKImageBrowserView image quality changing with redraw (From: Adam Berger <email@hidden>)

  • Prev by Date: Unable to write in InfoPlist.strings file from cpp
  • Next by Date: Re: Unable to write in InfoPlist.strings file from cpp
  • Previous by thread: Re: IKImageBrowserView image quality changing with redraw
  • Next by thread: Re: IKImageBrowserView image quality changing with redraw
  • Index(es):
    • Date
    • Thread