[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Graphics Rounding (was Re: Pixel-aligned autoresizing)
From: |
Philippe Roussel |
Subject: |
Re: Graphics Rounding (was Re: Pixel-aligned autoresizing) |
Date: |
Mon, 11 Jul 2011 09:00:39 +0200 |
Hi
Le dimanche 10 juillet 2011 à 21:51 +0200, Fred Kiefer a écrit :
> 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?
I'm sorry, my description of the problem wasn't really clear.
Vertical resizing of the main window affect the vertical position of the
bitmaps, horizontal resizing affect the horizontal position.
The strange thing is that the nsbox that contains those bitmap buttons
has a fixed size and so isn't affected by the window resizing but I
guess it depends at what stage the rouding is done (on relative
coordinates or not).
Philippe
- Re: Pixel-aligned autoresizing, (continued)
- Re: Pixel-aligned autoresizing, Eric Wasylishen, 2011/07/08
- Re: Pixel-aligned autoresizing, Fred Kiefer, 2011/07/08
- Re: Pixel-aligned autoresizing, Philippe Roussel, 2011/07/09
- Graphics Rounding (was Re: Pixel-aligned autoresizing), Eric Wasylishen, 2011/07/09
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), Fred Kiefer, 2011/07/10
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), Eric Wasylishen, 2011/07/10
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), Riccardo Mottola, 2011/07/11
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), Eric Wasylishen, 2011/07/11
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), Tim Schmielau, 2011/07/11
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), Riccardo Mottola, 2011/07/12
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing),
Philippe Roussel <=
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), Eric Wasylishen, 2011/07/12
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), Philippe Roussel, 2011/07/13
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), David Chisnall, 2011/07/20
- autoresizing in the case of negative flexible space (was Re: Pixel-aligned autoresizing), Tim Schmielau, 2011/07/22
- Re: autoresizing in the case of negative flexible space (was Re: Pixel-aligned autoresizing), Fred Kiefer, 2011/07/23
- Re: autoresizing in the case of negative flexible space (was Re: Pixel-aligned autoresizing), Tim Schmielau, 2011/07/23