Re: Image cache: Where is it and how do I refresh it?
Re: Image cache: Where is it and how do I refresh it?
- Subject: Re: Image cache: Where is it and how do I refresh it?
- From: Lon Giese <email@hidden>
- Date: Tue, 30 May 2006 11:07:12 -0700
From: Lon Giese <email@hidden>
Date: May 30, 2006 10:25:15 AM PDT
To: Gregory Weston <email@hidden>
Subject: Re: Image cache: Where is it and how do I refresh it?
Thanks, Lon.
You're very welcome, maybe helping you might boost my 'cocoa mailing
list karma credit card' a little and get some of my questions
answered...
Anyhow it is my understanding that the cache is only used in scaling
operations to scale the original image to the screen, since scaling is
expensive it makes sense to cache only when scaling is actually
required... The image either draws to the screen from the original
un-scaled image or from the cache... the problem is there are many
different formats the original image can be in i.e. integer, floats,
rgb, rgba, cmyk, different bytes per sample etc. etc. this is the image
you access with the bytes pointer...
Now this is not really explained in the documentation, but from my
experience working with computer graphics I surmise this:
1) The original bytes are converted to some common format and placed in
the mysterious unmentioned cache
2) if you request caching, which is totally optional, to optimize your
application
The image in the mysterious cache is scaled and placed in the
documented cache...
3) when the image is composited it is drawn from the cache if present
If not present it is drawn from the mysterious cache and scaled if
necessary.
4) recache is not really what it sounds like, it is a memory management
mechanism (oops I'm not supposed to talk about that), it frees the
cache! but has the added effect of rebuilding the cache automatically
if the image ever needs to be composited again and rebuilt from the
mysterious cache, not from the original image data!
This must be true because retaining the original image data is also
optional, so if the cache is optional and the original bytes are
optional then from where does the image get drawn?
Under this scenario it makes sense not to retain the original data if
you do not plan to modify it and instead modify the view directly.
Otherwise the one image you loaded can become three images in three
different states of composition! Unfortunately there appears to be no
way to free the mysterious cache, when the documented cache can do just
nicely when the image needs to be scaled but not modified... The best
scenario is to use only 72 dpi images, then you can cache none and free
the original image data and have the image in memory only once.
If you load the image by reference thats a whole nuther can of worms
and the above probably does not apply in its entirety.
Another thing to be aware of is that the original bytes may get
automatically re-formated into a different number of bytes per scan
line. The docs say to request the bytes per line every time (or only
after the image has been composited the first time?) you manipulate
the original bytes. It does this to optimize memory access. So if your
original image had say 303 bytes per line it would be padded to 304 (or
some such figure) bytes per line.
With all this said and done, and all the conversion's going on the docs
recommend drawing directly to the view. But if your original image is
300dpi and the screen is 72 dpi you are going to lose resolution when
saving the modified image if you do it that way .
Then there's a whole nuther issue when it comes to an NSImage that has
a different size than the representation... But we'll leave that for
now.
Lon
WooHoo the ultimate Mac App for 'The Sims 2' power users.
http://www.modthesims2.com/showthread.php?p=1239629
On May 30, 2006, at 3:22 AM, Gregory Weston wrote:
On May 28, 2006, at 6:35 AM, Lon Giese wrote:
[My issue is unexpected caching after messing with the pixel buffer
of an NSBitmapImageRep]
I'm surprised no one has replied to this question, but I'll give it a
shot...
I think I remember reading something that you need to request the
bytes pointer (even if you don't ned it) every time you update the
pixel buffer - that has the implicit effect of informing NSImage that
the pixel buffer has/will change... Let me know if that worked for
you... I don't remember exactly where I read that, probably in the
image architecture docs.
Surreal as this sounds, this works. Removing and adding the existing
rep doesn't do anything. Sending recache to the NSImage didn't help
either. But sending bitmapData to my image rep does apparently signal
the image (via the rep, I presume) that its cache is likely to be
stale.
Thanks, Lon.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden