Re: IKImageBrowserView image quality changing with redraw
Re: IKImageBrowserView image quality changing with redraw
- Subject: Re: IKImageBrowserView image quality changing with redraw
- From: Mike Abdullah <email@hidden>
- Date: Tue, 8 Dec 2009 12:29:25 +0000
On 8 Dec 2009, at 00:01, 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?]
NSImage is threadsafe as long as you're not mutating it.
http://developer.apple.com/mac/library/releasenotes/cocoa/AppKit.html
"NSImage: Clarifying the contract for threading"_______________________________________________
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