[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
it.
Cheers,
Quentin.
- Re: Image size, DPI (was Re: Gorm is broken), (continued)
- Re: Image size, DPI (was Re: Gorm is broken), Riccardo Mottola, 2011/05/07
- Re: Image size, DPI (was Re: Gorm is broken), Eric Wasylishen, 2011/05/07
- Re: Image size, DPI (was Re: Gorm is broken), Riccardo Mottola, 2011/05/07
- Re: Image size, DPI (was Re: Gorm is broken), Fred Kiefer, 2011/05/08
- Re: Image size, DPI (was Re: Gorm is broken), Eric Wasylishen, 2011/05/09
- Re: Image size, DPI (was Re: Gorm is broken), Fred Kiefer, 2011/05/09
- Re: Image size, DPI (was Re: Gorm is broken), Eric Wasylishen, 2011/05/10
- Re: Image size, DPI (was Re: Gorm is broken),
Quentin Mathé <=
- Image size, DPI (was Re: Gorm is broken), Eric Wasylishen, 2011/05/03