gnustep-dev
[Top][All Lists]
Advanced

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

Re: Graphics Rounding (was Re: Pixel-aligned autoresizing)


From: Fred Kiefer
Subject: Re: Graphics Rounding (was Re: Pixel-aligned autoresizing)
Date: Sun, 10 Jul 2011 21:51:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11

On 09.07.2011 21:04, Eric Wasylishen wrote:
Hi Philippe,

The jumping is caused by our use of rint() in NSButtonCell - in fact, I think we should 
avoid rint() entirely for graphics, because it uses a "round halfway cases to the 
nearest even integer" algorithm; so 1.5 rounds to 2, but 2.5 also rounds to 2.

The annoying thing is that none of the C standard library functions implement a 
good rounding algorithm for graphics. c99's round() rounds halfway cases away 
from zero. This is probably OK in practice but not ideal, since it means the 
location of the coordinate system origin affects the rounding. I think the best 
algorithm for graphics is round-towards-infinity, so just floor(x+0.5). I 
wonder if we should just introduce this as a function for internal use, like 
GSRoundTowardsInfinity().

Eric

Hi Eric,

could you please explain why you think that one of these rounding methods is better suited for graphics than the others? For me they are all equally problematic :-( If we ever change to another function we will have to make sure it is available equally on all supported systems. That way why I wanted to stick with rint() for all cases as we already try to support that everywhere.

Fred

PS: I also don't see how pure horizontal resizing may affect the vertical position of a subview. Is this the case that mentioned earlier, but couldn't come up with a real test case for?




reply via email to

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