[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSImage and ICNS
Dr. H. Nikolaus Schaller
Re: NSImage and ICNS
Thu, 9 Jun 2011 08:33:05 +0200
Am 09.06.2011 um 07:49 schrieb Eric Wasylishen:
> Hi Austin,
> On 2011-06-08, at 5:08 PM, Austin Clow wrote:
>> Since I am porting an application from Mac OS X to GNUstep, I have a lot of
>> .icns. I have already reported a bug (#33475) about NSImage using the
>> smallest image from the .icns. That has been changed, it seems so that the
>> largest is the default. Tho I am not entirely certain because I am seeing a
>> few issues with .icns still.
>> The first thing that is clear is in GWorkspace (so I am not sure if the
>> issues rests in that app specifically or AppKit). I replaced
>> common_Folder.tiff with common_Folder.icns (attached to this file), to see
>> what the effect would be. What you notice is that the representation for the
>> size required by the icon is not being drawn. (at least now it is the
>> biggest being scaled down, rather than the smallest being scaled up as it
>> was before)
> I see.
>> The other thing is evident in the Tiles, and the icon that is drawn there. I
>> have a .icns file for my application's icon. It seems that the icon is not
>> being scaled at all but is rather being clipped.
> I think this is caused by the implementation of NSAppIconView in
> NSApplication.m having bugs/mistakes in how it draws the icon.
>> I am refraining from posting this to the bug database until I am sure what
>> is going on and where it is originating. I believe this is stemming from the
>> fact that representations (of multiple sizes at least) are not common on
>> GNUstep and so perhaps GWorkspace, NSImageVIew et cetera have not been
>> programmed with that expectation, and that work will need to be done.
> Thanks for bringing this up, I think it's an important thing to get right.
> I started a test case in GSTest here:
> with some handy sample images:
> testICNSIcon.icns contains icons at 16, 32, 128, 256, and 512 pixels, and
> each size is labelled so you can easily see which one is drawn.
> testTIFFIconWithAllImages72DPI.tiff is the same as the ICNS but in TIFF
> format, and each sub-image is set to 72dpi.
> testTIFFIconWithAllImages72DPIDescendingSize.tiff is the same as the previous
> but the order of images within the tiff goes from largest to smallest.
> 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.
> I should point out that according to the documentation, the way that NSImage
> picks a best representation when there are representations with different
> point sizes (as is the case with icons) is undefined.
It is described here (section "How an Image Representation Is Chosen"):
and done by -bestRepresentation:
But beware: it is deprecated in 10.6.
> One potential solution I have in mind is modifying -[NSImageCell
> drawInteriorWithFrame:] so it manually chooses an image rep based on the size
> that the cell is going to be drawn in. That's only the first thing that came
> to mind, though; it probably needs some closer investigation.
On Cocoa it is fully automatic within NSImage (i.e. it scans and scores all
image reps it knows) so there is no special case to be considered in any NSView