gnustep-dev
[Top][All Lists]
Advanced

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

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


From: Eric Wasylishen
Subject: Re: Image size, DPI (was Re: Gorm is broken)
Date: Sat, 7 May 2011 15:53:05 -0600

On 2011-05-07, at 6:26 AM, Riccardo Mottola wrote:

> Hi,
>> 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.
> 
> Riccardo


Hi Riccardo,
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.)

I committed a patch to NSButtonCell which rounds the image location, but there 
are probably other places it is needed. But I'd like to hear other people's 
opinion on this because I could be overlooking something.

On a related note, I think the Cairo backend also rounds the coordinates of 
path points - shouldn't we get rid of that as well?

Cheers,
Eric


reply via email to

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