[restricting this to gimp-devel, since this is purely technical stuff]
GSR - FR ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] (2004-01-19 at 1524.44 +0100):
> > [technical discussion :)]
> > I think I already explained why I prefer the set of ratios based on
> > the idea of "homogenous zooming". So the rest of this Mail focuses
> > on the technical issues of your patch.
>
> The last patch I sent does homogenous zooming, has no more (known)
> floating issues (I am not gonna bet about floats, what is more, not
> gonna bet about Gimp either, I saw some warnings about aliasing in
> other parts, and I already had enough with C guts) and is small, it
> just fits in place with the old code instead of more deep changes.
True. (These "break strict aliasing rules" warnings however are harmless
according to Yosh.)
> [... code]
> > As you can see it compares floats with <= and >= and so avoids
> > tests for real equalness. The little "jump" done by multiplying by
> > 1.1 (which is a bit arbitrary chosen, but should be smaller than the
> > factors between the presets) makes it even more robust IMHO.
>
> So in the end both do a list of presets. Main difference is that mine
> is simetrical (that can be good or bad) and uses a typical search
> system. BTW, the CLAMP should be 255 or 256?
Well, I'd still prefer "real" homogenous zooming, but can see the issues
you and some other people seem to have with it. The stuff that is
currently in CVS (that tries to do homogenous zooming and forces the
fractions towards small numerator/denominator - "sane" fractions)
would be incredibly hard to tweak to get the desired behaviour (without
presets that is).
The Code snippet is part of an API change, that allows to specify floats
as the magnification factor consistently. The 255 basically was imposed,
because the earlier code encoded the fractions in a single integer and
is limited to that value. When I changed that to floats, that limit
became meaningless and I choose 256 over 255, since this is the logical
successor in the sequence.
> [...]
> > I hope you can accept this as a technical criticism of your patch, it
> > might solve your floating point problems with a different approach.
> > It also should work with a different set of presets.
>
> Problems solved... what do you mean with different set? Both can be
> adjusted, that was one of the differences from my first to second
> version, the table changed.
I mentioned this, because the main motivation for you to start with the
patch seemed to be that you were unhappy about the way the current CVS
code is stepping, which is based on homogenous zooming with less nice
fractions. I wanted to express that - contrary to the current CVS code -
tweaks to the presets are possible.
Ok. We now have your plug-n-play patch to solve the zooming issue and we
have a patch from me, that is a lot more invasive, needs some more
attention for some things, but also fixes more things (API, Zoom-dialog).
Unfortunately these two patches basically exclude each other and it will
come to no surprise to you, that I'd prefer to see my own patch in 2.0.
However, because it is so intrusive I won't commit it until somebody
read my patch and gives me the OK to do it.
Bye,
Simon
--
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
