Am 09.06.2011 um 09:28 schrieb Dr. H. Nikolaus Schaller:
Am 09.06.2011 um 09:15 schrieb Eric Wasylishen:
From some brief experimentation on Cocoa, it seems that ICNS files are given special treatment: If you create an NSImageView with an NSImage loaded from an ICNS file, resizing the image view will cause the best-sized representations to be used (the smallest one which is larger than or equal the destination size). However, if you do the same thing with either of the TIFF files I posted above, only the first sub-image in the TIFF is used. I'm not sure why this is; it seems like a bug in Cocoa.
I am not sure if Cocoa handles multi-image TIFF files at all and always uses the first (sub)image.
Right. The instructions there have to be read very carefully, though - by "resolution" they are referring to DPI. If the representations have the same DPI, color depth, and color space, but different dimensions (in points), by following that set of instructions the best representation would be "operating-system dependent". At least, that's how I interpret it.
Yes, but as far as I know, the rect given to -[NSImage drawInRect:...] has no influence on the choice of representation to use to draw with (in either Cocoa or GNUstep). If we have a TIFF or ICNS file with different versions of an icon at 16x16, 32x32, 128x128, etc, and if we want to draw that in an NSImageView, and we want the frame size of the image view to determine which image rep is chosen, we can't just rely on the built-in image rep matching of NSImage. That's why I was suggesting we might need to implement a special case in NSImageCell which uses the frame to draw in to choose an image rep.
Hm. Why should the frame size influence resolution? The screen resolution doesn't change if you make windows smaller or larger. The scoring mechanism should find the best representation for a given pixel density of the screen.
This may only have an influence if you want to scale (enlarge) the image. I think this should be embedded in
which can choose any representation that best its the scaled rect (I have no idea how that works internally).
In that case we must enlarge a finer resolution than the default. I just found that 10.6 appears to address this with a new method:
And one more thought about the reason why it is as it is. This may be the way Postscript/PDF works. There, you have to choose some bitmap that you must encode into the PDF file (I think in TIFF). Later the CTM is set controlling scaling etc. and the bitmap is stamped on paper. If the same image is drawn several times in different scales, only the CTM changes. This explains why choosing the best representation must know the device resolution in advance and why scaling appears not to influence the choice of a representation.
But this is only a theory...