Re: [Gimp-developer] Re: Re: Alternative zoom algorithm
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: For example, in C, the compiler is legally allowed to transform: r = (1 - a) * b; into: r = a - a * b; Which might not be the same value. If that is a problem, you either have to use more sequence points (i.e. multiple statements), or you need to use fortran, where these kinds of transformations are not allowed :) I assume you mean r = b - a * b, but even then that's the first I see something like this. AFAIK that is not what sequence points do. In (1 - a()) * b() a() might be evaluated before b() or the other way around, you never know. Sequence points ensure that everything before them is executed first. That's what I know sequence points are for; I would be very much surprised if the compiler is allowed to do symbolic algebra. I could be wrong of course (it wouldn't be the first time). Do you have any pointers to relevant online resources? -- Codito ergo sum Roel Schroeven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: The GIMP 2.0pre2
Hi,
The most recent installment from the GIMP production line, version
2.0pre2, is available now for perusal, downloading, evaluation, testing
and use from
ftp://ftp.gimp.org/pub/gimp/v2.0/testing/
or from one of the mirrors listed at http://gimp.org/download.html
Since the last release, nearly 40 known bugs have been killed, and many
other small changes have been made during code reviews.
Given the relatively small number of bugs reported against our past
pre-release, we expect this to be the final pre-release before 2.0, so
we extra-appreciate the time you spend testing and breaking it.
Happy GIMPing,
Dave.
Bugs fixed in GIMP 2.0pre2
==
- 130828: Compile error with gcc 2.95 (Adrian Bunk)
- 35335: Curve tool doesn't conserve black (Simon)
- 130866: Remove multiple PNG entries in file type dropdown (Brix)
- 106991: Add mnemonics for all menu items (finished by Mitch)
- 130869: Add smaller image templates (Dave Neary)
- 130916: Handle multiline texts better (Mitch)
- 120424: Add dirty flag to default image title (Brix)
- 130912: Fix rounding errors in JPEG plug-in ([EMAIL PROTECTED])
- 131016: Add support for layer offsets in multipage tiff loading (Pablo
d'Angelo)
- 124073: Modify behaviour of zoom tool to avoid funny fractions (Dave
Neary, Simon)
- 131088: fix select-to-pattern script-fu (Mitch)
- 82478: Fix zoom handling in fractal explorer (Pedro Gimeno)
- 115793: Make thumbnail preview of indexed images match display (Pedro
Gimeno)
- 130471: Handle RGBA images correctly in the CEL plug-in (Dov Grobgeld)
- 131109: Remove EMX specific code (Sven)
- 130118: Handle GIMP2_DIRECTORY with non-UTF-8 characters correctly
(Tor Lillqvist, Sven)
- 82465: Make preview match image when image is greyscale (Sven)
- 92586: Force SF_IMAGE value to reflect the selected image (Sven)
- 116765: Fix selection artifacts while moving selections (Pedro Gimeno,
Mitch)
- 131215: Only call bind_textdomain_codeset when available (Reinhard
Geissler)
- 125141: Resolve API issues with GimpPixelFetcher and
GimpRegionIterator (David Odin, Maurits Rijk)
- 109078: Fix histogram for graylevel images (Pedro Gimeno, Mitch)
- 131146: Fix drag drop of patterns to layer masks (Dave Neary, Mitch)
- 128112: Use a better error message if help files are not present
(Mitch)
- 78732: Don't paste outside the visible screen, if possible (Mitch)
- 131561: Make Condensed fonts available for use (Manish Singh)
- 71922: Fix SuperNova preview for Alpha channel (David Odin)
- 82464: Fix SuperNova preview for greyscale images (David Odin)
- 121966: Fix SuperNova plug-in (David Odin)
- 110610: Allow user to choose file formats even if the current image
type is not supported by them (Pedro Gimeno)
- 131980: Fix crash in crop tool (David Odin, Sven)
- 131030: Allow saving data without pre-multiplying by alpha channel in
tiff plug-in (Pablo d'Angelo, Dave Neary)
- 125864: Guides behave correctly when spacing is set to 1px (Brix)
- 131721: Fix handling of alpha channels across undo steps (Mitch)
- 128025: Fix behaviour when there is a floating selection (Mitch)
- 131076: Make fuzzy select tool respect alpha channel in indexed mode
(Mitch)
- 131779: Improve indexed scaling dialog (Mitch)
- 127673: Overlapping widgets in gradient editor {Mitch)
Other contributions:
David Odin, Manish Singh, Simon Budig, Michael Natterer, Sven Neumann,
Tor Lillqvist, Henrik Brix Andersen
--
Dave Neary
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Re: Re: Alternative zoom algorithm
GSR - FR ([EMAIL PROTECTED]) wrote:
[EMAIL PROTECTED] (2004-01-17 at 1724.31 +0100):
a) It has a table of presets that is constructed in an ad hoc manner
without any explantation what the advantages to the user are.
Did your copy of the first mail I posted lacked:
Comments about the presets also welcomed, I just made a list of the
ones that seemed interesting while working always around some given
factor.
Well, I should have sent my first two mails in a different order then
perhaps. The second mail does exactly this: It discusses the presets.
So I guess thats not the reason for you to be so offended.
The first mail I sent discusses the way this IMHO should be implemented.
In fact I did implement it in my local tree here yesterday and it turns
out that it is a pretty big change, since I noted a lot of brokeness
in the gimpdisplayshell API (the ratio 16:1 is encoded as both 1601
(decimal) and 0x1601 (hexadecimal) in different places of the code).
Because of the size of my patch it might be too late to put this
into 2.0. I think it is the right thing to do, but it might have to
wait (the patch is attached to bug 131563).
So in the retrospective the only reproach I have to make to myself is
the choice of the word evil in IRC. I'd like to apologize for that -
rest assured that I would not have used that word in a more formal
medium like mailing lists (Ok, I used it after you brought it up).
Please accept my apologies and I hope we can focus on a more technical
discussion.
[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.
I am not an expert on optimization levels, Assembler or whatever.
The only thing I know is, that it is hard to compare two floats
for equality. Part of the (huge) patch I mentioned above
(http://bugzilla.gnome.org/showattachment.cgi?attach_id=23503)
is a function, that calculates the next zoom step (float) based on a
given (float) zoom step. It looks like this:
gdouble
gimp_display_shell_scale_zoom_step (GimpZoomType zoom_type,
gdouble scale)
{
ginti, n_presets;
gdouble new_scale;
/* This table is constructed to have fractions, that approximate
* sqrt(2)^k. This gives a smooth feeling regardless of the starting
* zoom level.
*/
gdouble presets[] = {
1.0 / 256, 1.0 / 180, 1.0 / 128, 1.0 / 90,
1.0 / 64, 1.0 / 45, 1.0 / 32, 1.0 / 23,
1.0 / 16, 1.0 / 11, 1.0 / 8, 2.0 / 11,
1.0 / 4, 1.0 / 3, 1.0 / 2, 2.0 / 3,
1.0,
3.0 / 2, 2.0, 3.0,
4.0,11.0 / 2, 8.0, 11.0,
16.0, 23.0, 32.0, 45.0,
64.0, 90.0, 128.0,180.0,
256.0,
};
n_presets = G_N_ELEMENTS (presets);
/* Zooming in/out always jumps to a zoom step from the list above.
* However, we try to guarantee a certain size of the step, to
* avoid silly jumps from 101% to 100%.
*/
switch (zoom_type)
{
case GIMP_ZOOM_IN:
scale *= 1.1;
new_scale = presets[n_presets-1];
for (i = n_presets - 1; i = 0 presets[i] scale; i--)
new_scale = presets[i];
scale = new_scale;
break;
case GIMP_ZOOM_OUT:
scale /= 1.1;
new_scale = presets[0];
for (i = 0; i n_presets presets[i] scale; i++)
new_scale = presets[i];
scale = new_scale;
break;
case GIMP_ZOOM_TO:
break;
}
return CLAMP (scale, 1.0/256.0, 256.0);
}
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.
Something similiar could be implemented directly in
gimp_display_shell_scale (). The only trick is, to get the numerator and
denominator for the fraction in the gimpdisplayshell.
In current CVS there is the function
gimp_display_shell_scale_calc_fraction (), that calculates a fraction
for a given float. It uses continued fractions, which kind of ensures,
that things like 2.0 / 3.0 really result in 2/3. You could use this
to determine the fraction for the gimpdisplayshell (similiar as to how
it is used now).
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.
Thanks,
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
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
[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
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig wrote: [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.) Well, not all are harmless. Just that a lot of them are spurious, but some of them do signify real problems. It's a mess. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig [EMAIL PROTECTED] wrote: 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.) Just a sidenote, unless caused by a bug in the compiler, these warnings are never harmless. They might not cause problems with current gcc, but there is no guarentee that the code will do as expected with other compilers or future versions of gcc, unless one uses -fno-strict-aliasing, which can be a major performance problem in some cases. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Re: Alternative zoom algorithm
[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. [... 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? [...] 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. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
