[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Image size, DPI (was Re: Gorm is broken)

From: Quentin Mathé
Subject: Re: Image size, DPI (was Re: Gorm is broken)
Date: Mon, 9 May 2011 14:04:58 +0200

Le 7 mai 2011 à 23:53, Eric Wasylishen a écrit :

> On 2011-05-07, at 6:26 AM, Riccardo Mottola wrote:
>>> Yes. However, the value 72 dpi is important in GNUstep/Cocoa because 1 
>>> point in the window's base coordinate system = 1 pixel, and a point is 1/72 
>>> inch. (even though it's an arbitrary number in some sense because no modern 
>>> desktop screens are really as low resolution as 72 PDI).
>>> So drawing an image with 1 pixel = 1 pixel means treating the image as if 
>>> it is 72 DPI, which is what the code did before my patch, i.e. it set the 
>>> dimensions in points to the dimensions in pixels.
>>> I just checked on Cocoa and it ignores the dpi of PNG's and assumes them to 
>>> be 72dpi, however it reads and uses the dpi of TIFF's exactly as GNUstep 
>>> does now. In addition, Cocoa supports multi-image TIFF's, something I would 
>>> like to add support for to GNUstep. This means we can provide high-res 
>>> versions of the default artwork which are only used when a scale factor>  1 
>>> is set.
>> I took Terminal's icon and UI elements and explicitly set them to 72dpi. The 
>> Icon seems to draw quite well, the UI icons in the preferences (the cursor 
>> buttons) seem to be slightly blurred, as if drawing was scaled by a factor 
>> close to 1, but not being 1.
> I finally figured this out, as well as the blurry button icons in NSSavePanel.
> These happened when I committed r32895, where I reimplemented the 
> -composite... methods in NSImage on top of the -drawIn... methods. A side 
> effect of this is that drawing images with -compositeToPoint: no longer 
> automatically pixel-aligns them, so if you composite an image at (0.5, 0.5), 
> it will appear blurred. This behaviour matches Cocoa though.
> (I found another small difference between Cocoa and GNUstep - autoresizing in 
> Cocoa seems to pixel aligns view frame origins, whereas in GNUstep it can 
> give view frames fractional origins. This didn't cause problems in the past 
> since we were rounding image locations in the backend. GNUstep is still more 
> lenient than Cocoa - for example if you put a NSImageView or an NSButton with 
> a frame origin at (0.5, 0.5) in Cocoa the image will appear blurred. I have a 
> test app that shows off various cases which I'll add to GSTest when I get a 
> chance.)

It's great you figured that out. I have observed that pixel alignement where 
not the same between GNUstep and Cocoa in some cases, but I was clueless about 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]