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

[Eric Wasylishen]

>> Ok. I agreed it should be well tested if changed. Based on a quick
>> check, however, cairo's and Cocoa's default behaviour are exactly the
>> same , i.e. the examples here:
>> http://www.cairographics.org/FAQ/#sharp_lines produce the same
>> results on Cocoa, so it doesn't appear that cocoa does any rounding
>> below the level of NSView implementations.
> 
> Are you saying that Cocoa basic drawing operations have the same blur effect 
> for horizontal single pixel lines?
Yes. To stroke 1pt wide horizontal or vertical lines with no blurriness you 
need to put the endpoints at (x+0.5, y+0.5), same as cairo. Integer-aligned 
rectangle fills have no blurriness, same as Cairo.

> Does this affect only the CoreGraphics functions or also the NSBezierPath 
> methods?
Both CG and NSBezierPath methods.

> And what about the still supported PS functions?
I wasn't able to find these on my system, but I assume they would be the same 
as CG/NSBezierPath

The one that's different is NSFrameRect (and probably the other related 
functions). It's implemented using rect fills so you need to give it an 
integer-aligned rect to get no blurriness. GNUstep's implementation of 
NSFrameRect appears to exactly match Cocoa's already.

> If this is the case we need to move the half pixel correction up one level 
> into gui. I remember that before that correction was added use interface 
> elements with the cairo backend looked less sharp.


Ok. I have a test case I'm working on which I'll add to GSTest.

I just did a quick search in -gui and all of the DPSlineto/PSlineto's are in 
GSThemeDrawing.m. Other than that, there are only a handful of uses of 
-[NSBezierPath strokeRect:] and -[NSBezierPath strokeLineFromPoint:toPoint:] in 
gui. My first reaction is that most of these should probably be using 
NSFrameRect since that makes the geometry easy to work with and always 
pixel-aligns as long as the rect coordinates are integers.

Eric