Hi,

GSR / FR wrote:

I saw that zoom has been changed following bug 124073. After trying it, I did not liked it. Personally I think it gives too much importance to extreme zooms, forgeting most people work around 100%. 4000 to 20 pix images in a reasonable size monitor is what I normally see, not 40000 pix or people with one pixel painted as 128*128 screen pixels. I also did not liked that it quickly went to fractional numbers in which one of X:Y is not 1, cos it does not look very pleasing due the fast way Gimp interpolates when displaying.

I like the idea of special-casing near-100% ratios (and so does Alan Horkan, from what I can tell from the bug he submitted recently). A LUT is a good way to go for them too, I think.

There are some issues with the patch, though. I don't really get what's happenning in the if (src == 1 && dest == 1) clause, and I'm not sure completely reverting the old change is the way to go.

Perhaps it might be an idea to have some smallish set of presets which are favoured as is suggested in bug 124073 - something from say 8:1 to 1:8, which would cover most common usages, but with zooming allowed outside that range, using the new continued fractions algorithm and a sqrt(2) zoom factor.

Help welcomed about how to make it work with typical optimization level. Comments about the presets also welcomed, I just made a list of the ones that seemed interesting while working always around some given factor.

I would go for
12.5% 18% 20% 25% 33% 50% 75% 100% 150% 200% 300% 400% 600%

That gives you a smallish set of presets, with extra focus around 100%, and outside that you let her fly with the newer algorithm.

Cheers, Dave.

dneary@free.fr (2004-01-16 at 2215.53 +0100):

There are some issues with the patch, though. I don't really get what's happenning in the if (src == 1 && dest == 1) clause, and I'm not sure completely reverting the old change is the way to go.

It is the flip point, and I found the sequence is buggy (100 -> 150 -> 200 -> 100, missing the 150 step when going back). It is special cos 1.0 == (1.0 / 1.0). You are sitting in the middle of the roof, so to speak. Once you are in the sequence, you can use the normal look up.

I would go for
12.5% 18% 20% 25% 33% 50% 75% 100% 150% 200% 300% 400% 600%

That gives you a smallish set of presets, with extra focus around 100%, and outside that you let her fly with the newer algorithm.

The sqrt algorithm seems to have problems with rounding, btw. I could do a different set, with a first 8 at +1 to last 8 at +32 (first group would be 8, not 16). Or even scaling the factors and playing with the other part of the fraction (I think that would fix the buggy case above). The adventage is that all would be handled with the same code (I am not happy with so many if and switch).

GSR

Hi,

I don't think it makes sense to discuss patches here. We should concentrate on the behaviour we'd like to see and do the implementation later.

In my opinion it is important that the series of zoom ratios is linear. The current implementation fulfills this requirement, it favors zoom ratios such as 1:1, 1:2, 1:4, ... and still provides the linearity and the intermediate steps that the 1.2 implementation was missing. I don't see a reason to change it.

Sven

GSR / FR (famrom@infernal-iceberg.com) wrote:

I saw that zoom has been changed following bug 124073. After trying it, I did not liked it. Personally I think it gives too much importance to extreme zooms, forgeting most people work around 100%. 4000 to 20 pix images in a reasonable size monitor is what I normally see, not 40000 pix or people with one pixel painted as 128*128 screen pixels. I also did not liked that it quickly went to fractional numbers in which one of X:Y is not 1, cos it does not look very pleasing due the fast way Gimp interpolates when displaying.

I think it is very important, that zoom behaves homogenous, regardless of the actual zoom step. So the user will have a consistent experience when he works with low and high resolution images (but see below).

So I coded a different version that gives a full integer range in the 16:1 to 1:16, plus two extra steps near 1:1 (it is a special point, so I made the extra code an improvement and not only a way to make it work), and for extreme zooms it gives integers but reduced number.

looking at your patch I believe it is unnecessary complicated, because it tries to deal with the problem on the fractions level.

I'd like to propose an alternate approach.

Let Gimpdisplayshell have a percentage (float), that describes the desired zoom ratio as exact as possible. This is the value that gets manipulated in the various zoom functions. The fraction necessary to do the actual zooming of the image would be calculated from that in the display code. When we stop exposing this fraction to the user interface we no longer have to worry about "nice" fractions.

With this approach it is trivial to implement different approaches for the zooming strategy: "homogenous zooming" would multiply/divide by sqrt(2), "preset zooming" would have a lookup table with percentages for the different zoom steps and move back/forward [1] in it (this also easily adresses the "nice looking zoom levels" problem, simply select the percentages so that they result in the desired fractions). The user then could e.g. select the strategy in the preferences.

I believe this could simplify the whole issue a lot.

Bye, Simon

[1] it might be useful to guarantee a minimum zoom step since it does not make much sense to scale from 102% down to 100%. But this also is trivial to implement.

Simon Budig (Simon.Budig@unix-ag.org) wrote:

With this approach it is trivial to implement different approaches for the zooming strategy: "homogenous zooming" would multiply/divide by sqrt(2), "preset zooming" would have a lookup table with percentages for the different zoom steps and move back/forward [1] in it (this also easily adresses the "nice looking zoom levels" problem, simply select the percentages so that they result in the desired fractions). The user then could e.g. select the strategy in the preferences.

To explain what I mean by "homogenous zooming":

when viewing an image at 100% zoom in would result in

100% * sqrt(2) = 141% 100% * sqrt(2)^2 = 200%
100% * sqrt(2)^3 = 283%
100% * sqrt(2)^4 = 400%
etc.

Zoom out would result in

100% / sqrt(2) = 71% 100% / sqrt(2)^2 = 50%
100% / sqrt(2)^3 = 35%
100% / sqrt(2)^4 = 25%
etc.

This has the advantage that the behaviour is exactly predictable in every zoom level, since always exactly the same rectangle of the viewable area gets magnified. This also would work for other starting zoom levels.

It seems that some people are scared away by the "weird" percentage numbers (huh? 283%?) and seem to prefer nice ratios instead.

Ok, this makes things a bit more complicated. I tried to figure out a set of ratios that tries to emulate the behaviour described above while using more or less "nice" fractions. These presets could be used for "preset zooming", i.e. zoom in/out would jump to the next bigger/smaller preset. Of course this is not as predictable, since you have to know your current zoom level to know in advance what area will be magnified. This table tries to minimize this effect.

sqrt(2)- percentage used based preset ratio

0.39 -> 0.39 = 1:255 0.55 -> 0.56 = 1:180
0.78 -> 0.78 = 1:128
1.10 -> 1.11 = 1:90
1.56 -> 1.56 = 1:64
2.21 -> 2.22 = 1:45
3.12 -> 3.12 = 1:32
4.42 -> 4.44 = 2:45
6.25 -> 6.25 = 1:16
8.84 -> 9.09 = 1:11
12.50 -> 12.50 = 1:8
17.68 -> 16.67 = 1:6
25.00 -> 25.00 = 1:4
35.36 -> 33.33 = 1:3
50.00 -> 50.00 = 1:2
70.71 -> 66.67 = 2:3

100.00 -> 100.00 = 1:1

141.42 -> 150.00 = 3:2 200.00 -> 200.00 = 2:1
282.84 -> 300.00 = 3:1
400.00 -> 400.00 = 4:1
565.69 -> 600.00 = 6:1
800.00 -> 800.00 = 8:1
1131.37 -> 1100.00 = 11:1
1600.00 -> 1600.00 = 16:1
2262.74 -> 2250.00 = 45:2
3200.00 -> 3200.00 = 32:1
4525.48 -> 4500.00 = 45:1
6400.00 -> 6400.00 = 64:1
9050.97 -> 9000.00 = 90:1
12800.00 -> 12800.00 = 128:1
18101.93 -> 18000.00 = 180:1
25600.00 -> 25500.00 = 255:1

Of course it always is possible to choose other zoom levels interactively with the lens tool etc. This leaves the question what should happen when the user zooms in/out from an arbitrary zoom level. IMHO Zoom in/out always should result in a zoom level from the list above. But - as briefly mentioned in an earlier mail - it would not make very much sense to jump from 102 % to 100% when the user wants to zoom out.

I'd suggest to guarantee a minimum zoom out, e.g. by a factor of 0.9.

Examples:

(Zoom out) 102 % * 0.9 = 91.8 % ---> next smaller zoom preset is 66.67 % so we pick this one.

2 % * 0.9 = 1.8% --> next smaller zoom preset is 1.56%

(Zoom in) 1500 % / 0.9 = 1666.66 % ---> next bigger zoom preset is 2250.00 %

I hope you get the idea.

Ideas? Suggestions? (But please do not complain about the lack of your favourite zoom level, trying to insert specific "missing" zoom levels in the table above would completely break the advantages of nearly homogenous zooming...)

Bye,
Simon

Simon Budig writes:
> This has the advantage that the behaviour is exactly predictable in > every zoom level, since always exactly the same rectangle of the > viewable area gets magnified.

Hear, hear! This seems like a big win to me. I'm all for this.

> It seems that some people are scared away by the "weird" percentage > numbers (huh? 283%?) and seem to prefer nice ratios instead.

Just a small matter of user education.

--tml

Simon.Budig@unix-ag.org (2004-01-17 at 0309.30 +0100):

Ideas? Suggestions? (But please do not complain about the lack of your favourite zoom level, trying to insert specific "missing" zoom levels in the table above would completely break the advantages of nearly homogenous zooming...)

After being pointed in IRC to check what other apps do, a search that resulted in similar things to what I was trying, going thru discarding what people is used to or the levels for typical images and finaly get my patch encouragingly classified as evil, I think I will stop wasting time and keep my ideas and suggestions to myself.

So I only have a question: why is homougenous zooming the holy grail that makes the rest of issues discardable? Something other than the words smooth or continous, which only make me think about animation and not about painting.

GSR

On Sat, Jan 17, 2004 at 01:26:09PM +0100, GSR - FR wrote:

what people is used to or the levels for typical images and finaly get my patch encouragingly classified as evil, I think I will stop wasting time and keep my ideas and suggestions to myself.

Get used to it, that's how gimp-developer works :(

Hi,

GSR - FR writes:

So I only have a question: why is homougenous zooming the holy grail that makes the rest of issues discardable? Something other than the words smooth or continous, which only make me think about animation and not about painting.

Homogenous scaling is predictable while your approach is just a set of preset aspect ratios that appear to be more or less arbitrary. So far you failed to explain the advantages of your approach. This makes it hard to judge which one would be better.

Sven

GSR - FR (famrom@infernal-iceberg.com) wrote:

Simon.Budig@unix-ag.org (2004-01-17 at 0309.30 +0100):

Ideas? Suggestions? (But please do not complain about the lack of your favourite zoom level, trying to insert specific "missing" zoom levels in the table above would completely break the advantages of nearly homogenous zooming...)

After being pointed in IRC to check what other apps do, a search that resulted in similar things to what I was trying, going thru discarding what people is used to or the levels for typical images and finaly get my patch encouragingly classified as evil, I think I will stop wasting time and keep my ideas and suggestions to myself.

I'd like to explain why I consider your patch as evil.

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.

b) according to yourself the behaviour of your patch changes depending on the existance of a certain printf.

c) Again in your own words apparently one version of your patch fails in certain zoom steps (this is taken from http://www.infernal-iceberg.com/gimp/gimpdisplayshell-scale.c.diff which right now reads:

--------- Rearranged a bit, excuse any inconvenience:

Working version, at least with -O0: http://www.infernal-iceberg.com/gimp/gimpdisplayshell-scale.c-cleaned.diff

Version with 3:4 and 3:2 zoom, but fails in 50 -> 100 and 100

Sorry, I believe that a patch that depends on the compilers optimization level has indeed a real problem - for me this is evil.

On a more social level you failed to explain what problem you wanted to solve with this patch in IRC. I thought hard about my proposal and I indeed think that I can justify why I am choosing this set of presets, although I still would prefer the fully homogenous version, but I can see that people have issues with weird zoom percentages.

So I only have a question: why is homougenous zooming the holy grail that makes the rest of issues discardable? Something other than the words smooth or continous, which only make me think about animation and not about painting.

The whole point is user experience. "Homogenous Zooming" - for a lack of a better word - would behave exactly the same in every zoom level, regardless if this is from 274% or from 300%. When zooming in always the same rectangular area would be magnified to the image window. The user would be able to estimate, how often he has to zoom in to get *this* detail at *that* size.

Compare this to the old behaviour some releases ago, described in bug #124073: from 1:3 it jumps pretty quickly in the details of the image, but from 67:189 the difference for zooming in/out is barely noticeable.

I adressed this by implementing a zoom function based on a mix between homogenous zooming and continued fractions (sorry for the word pretty close to continuous, but thats the name of the mathematical concept), which has been considered to work pretty well by some people.

Then you started to rework that thing *again* and failed to provide any argument [1], why 1:1, 1:2, 1:3, 1:4... etc. is better than my approach I did neither see the beauty of your concept nor the beauty of your patch, so my words on IRC probably were a bit harsh and I'd like to apologize for that.

With your patch the user would have to zoom in 8 times to go from 1:32 to 1:64, (magnifying a quarter of the visible area), but would have to zoom in 2 times to go from 1:2 to 1:4 (also magnifying a quarter of the visible area). With my proposal the user always would have to zoom in two times to magnify a quarter of the visible area [2].

In my earlier mail I presented a possible compromise between homogenous zooming (I hope I made the advantages of that approach clear) and 1:x based zooming. I think it keeps best of both worlds and would like to ask, that alternative proposals have a careful discussion of advantages vs. backdraws against this.

Thanks, Simon

PS: Not that it'd matter much, but this is the list of zoom steps photoshop uses (percentages):
1600, 1200, 800, 700, 600, 500, 400, 300, 200, 100, 66.7, 50,, 33.3, 25, 16.7, 12.5, 8.33, 6.25, 5, 4, 3, 2, 1.5, 1, 0.7, 0.5, 0.4, 0.3, 0.2, 0.1, 0.05, 0.025, 0.02
For the reasons mentioned above I don't think it is a very good set of steps...

[1] There was the argument, that a zoom step of 3:4 would look better than e.g. 5:7, but I cannot confirm that. Both ratios make jiggly lines from straight lines at 1:1, because of the non-interpolation of the display zooming.

[2] Please note, that this is because of the use of sqrt(2)=2^(1/2) as the factor between the zoom steps, if that is considered too coarse I could work out a table based on 2^(1/3), which would produce three zoom steps to magnify a quarter of the visible area.

Hi,

writes:

Get used to it, that's how gimp-developer works :(

Marc, your comment is highly inappropriate. Guillermo refererd to a discussion on #gimp and #gimp is IRC and not gimp-developer, the mailing list. IMO it has been very impolite of him to take things that have been said on the IRC channel to the mailing list. Only very few people reading this list are able to judge what has really been said, especially since Guillermo quoted completely out of context. Since you haven't been around on #gimp when this conversation took place, you are definitely not in the position to make such a comment.

Sven

hi,
On Fri, Jan 16, 2004 at 09:49:31PM +0100, GSR / FR wrote:

Hi:

I saw that zoom has been changed following bug 124073. After trying it, I did not liked it. Personally I think it gives too much importance to extreme zooms, forgeting most people work around 100%. 4000 to 20 pix images in a reasonable size monitor is what I normally see, not 40000 pix or people with one pixel painted as 128*128 screen pixels. I also did not liked that it quickly went to fractional numbers in which one of X:Y is not 1, cos it does not look very pleasing due the fast way Gimp interpolates when displaying.

i read a lot of the mail in the threads that followed. I tried to figure out the best way to handle this zoom problem.

i think that any functionality should be allowed and encouraged until the info dialog is fixed. maybe the zoom and the info can work together rather than separately.

if the user can distinguish the difference between the use of the image then TheGIMP could easier determine the set of rations to use.

for instance, in the info dialog the user could choose production and it would first, only accept xcf format for save and second, allow extreme zooms.

if the user toggled "screen" the ratios and save sizes could be limited to screen displays. Different print expectations could be expressed and many of the decisions for the new user could be preset and the GIMP could not just guess what would be best for everything.

seems like this is only one use that a better info dialog could help with. determining format and image mode would be easier. i have enough experience with the different image handling, i could help to make the decisions about what the zoom ratio should be if i know you are making a web image and the resolution and image mode that would be best (if you cannot figure it out yourself).

lets work on the info dialog. how can we make this thing work properly?

carol

On Sat, Jan 17, 2004 at 05:24:51PM +0100, Sven Neumann wrote:

writes:

Get used to it, that's how gimp-developer works :(

Marc, your comment is highly inappropriate.

Eh, really? Yes, maybe I should have said "that's how gimp developers work", which would be more approriate.

discussion on #gimp and #gimp is IRC and not gimp-developer

The discussion took partly place here also, so please take your dogs back and complain elsewhere about appropriateness.

you haven't been around on #gimp when this conversation took place,

Well, the discussion here was quite similar (although on #irc it seems to have been worse, which is not surprising to me, many people on #gimp are rather bigheaded and aggressive, much more so than on gimp-developer).

you are definitely not in the position to make such a comment.

Oh! I definitely am, having had many similar experiences on #gimp (and few here). However, may I ask you why you think you are in a position to judge this better? I don't think you are. You are welcome to drag this topic out again as I am sure you will do because you think you are something better, but I will stop going down to that level right now.

Marc Lehmann (pcg@goof.com) wrote: [...]

discussion on #gimp and #gimp is IRC and not gimp-developer

The discussion took partly place here also, so please take your dogs back and complain elsewhere about appropriateness.

you haven't been around on #gimp when this conversation took place,

Well, the discussion here was quite similar (although on #irc it seems to have been worse, which is not surprising to me, many people on #gimp are rather bigheaded and aggressive, much more so than on gimp-developer).

If you want to argue about personal matters please do it off the list.

The discussion started in bug #124073 and continued on IRC and now gets moved to these lists.

GSR wants to replace something I implemented and have put some thought in it. It should be me who is pissed because of this, however, instead of just defending my implementation I chose to offer a compromise on this list.

GSR did not yet convince me, that his implementation has any advantages over the current implementation in CVS and I will continue to ask for clarifications until I am convinced that replacing the implementation in CVS is a good thing.

Mainly his arguments seem to be: "100% is more important than extreme ratios" (please note that my implentation does not have *any* bias towards a certain zoom ratio, and I believe that this is a good thing. And if we need finer grained step it is a two line patch to replace sqrt(2) with something else) and that for some reason certain percentage/ratio numbers are more important than others, which I also doubt. There is no need for 1:7, when 1:6 visually basically looks the same.

The fact that certain ratios look bad with the current non interpolating code for the image view cannot be solved by restricting the ratios available. This has to be done in the view code. And btw. I doubt that 1:3 looks significantly better than 10:29.

Bye, Simon

On Sat, 17 Jan 2004, Marc wrote:

Date: Sat, 17 Jan 2004 20:22:05 +0100 From: Marc
To: Sven Neumann
Cc: gimp-user@lists.xcf.berkeley.edu, gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] Re: Alternative zoom algorithm

On Sat, Jan 17, 2004 at 05:24:51PM +0100, Sven Neumann wrote:

writes:

Get used to it, that's how gimp-developer works :(

Marc, your comment is highly inappropriate.

Eh, really? Yes, maybe I should have said "that's how gimp developers work", which would be more approriate.

I commend Sven for his diplomacy. I am very pleased by Simons explanation.

This may have been the way some of the GIMP developers have worked in the past but I hope that in future the GIMP developers will do just like Simon has done and explain his criticism in a fair and clear manner so that no one will have reason to get offended.

I think that more developers will be attracted to the GIMP if they are forgiven for impatient mistakes and the over enthusiasm of beginners and not knowing how things work around here but are given the chance to learn.

Sincerely

Alan H.

Simon.Budig@unix-ag.org (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."

Maybe I should have said more clearly: "Test values, just to get the ball rolling."

But I am sure it is hard to confuse with: "These are the tried and true values thou shalt use."

b) according to yourself the behaviour of your patch changes depending on the existance of a certain printf.

It seems I found a compiler / arch weird sceneario about floats. But from what I see, I was just unlucky, cos Gimp code has things like mine too, I just stressed the tests (press zoom keys for 5 secs after you are at the max was one of such tests) and it broke.

I have been checking the following docs, just trying to figure what it could be (first time I find a problem like this, and nobody I asked figured):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12331 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 http://gcc.gnu.org/bugs.html#nonbugs_general http://www.validlab.com/goldberg/paper.ps

And I have tried the following, and only the last worked: -O2
-O2 -ffloat-store
-O2 -fno-strict-aliasing
-O2 -ffloat-store -fno-strict-aliasing -O0

I have tried using gdoubles, gfloats or gldoubles (which failed about not defined even after including gtypes.h, so tried long double, but failed anyway), and declare all volatile except the array which I declared const, and still the only way is -O0.

Later Chris Want started reviewing the code, and we decided to put () and CLAMPing everywhere we had doubts, then it works. Only thing I can guess is that the opimization + fast repeat means rounding problems, and other methods that made the floats "behave" (slow or printf, ie), hide the problem.

c) Again in your own words apparently one version of your patch fails in certain zoom steps (this is taken from http://www.infernal-iceberg.com/gimp/gimpdisplayshell-scale.c.diff which right now reads:

I will scrap "release early, release often" and "submit so a disk crash does not mean lost work" from the list of wise phrases then.

I guess it would have been pretty nice to become mad alone instead of get people trying to help me and point me to valgrind, optimization levels, objdump and whatever they could think as useful.

[...]

Sorry, I believe that a patch that depends on the compilers optimization level has indeed a real problem - for me this is evil.

I just read the C code, and it "mentally" compiles. But the compiler does tricks and it fails. I am not an expert at this, I do not know C ANSI spec, GCC design or x86 blue prints like if I had wrote them myself, so I try my best.

Getting different values cos the compiler decides you can go with different data size depending if it keeps all or not in CPU is not fun, not at all. If you want to take the position of "not a bug", fine, I prefer the position of "float is float, not maybe a double or maybe a long double", specially cos if I want to get dirty, I should be using asm directly, not letting the compiler throw mud at me. I thought rounding was a tricky thing, now I know it is more than just tricky, it has a random factor.

On a more social level you failed to explain what problem you wanted to solve with this patch in IRC. I thought hard about my proposal and I indeed think that I can justify why I am choosing this set of presets, although I still would prefer the fully homogenous version, but I can see that people have issues with weird zoom percentages.

Proof of concept to get 1:n ratios to sweeten the interpolation and desire to avoid getting a "submit a patch" when requesting something, as I have got some (too many?) times in the past. Instead it seems that when I show patch I get a "discard your patch and talk about the request".

So I only have a question: why is homougenous zooming the holy grail that makes the rest of issues discardable? Something other than the words smooth or continous, which only make me think about animation and not about painting.

The whole point is user experience. "Homogenous Zooming" - for a lack of a better word - would behave exactly the same in every zoom level, regardless if this is from 274% or from 300%. When zooming in always the same rectangular area would be magnified to the image window.

Until both input and output is nicely interpolated, 274% will be less predicatable than 300%, it is less pleasing when you look and when you try to paint. Until I started this, Gimp was going with sqrt and no smooth interpolation, so I tried to start scratching my itch, share the results back and get suggestions. It seems I just managed to open hell's gates instead.

The user would be able to estimate, how often he has to zoom in to get *this* detail at *that* size.

I do not estimate, I zoom and stop when it looks suitable. Personally I have keys assigned to the power of 2 zooms (stops at 16, but up to present day I always worked with images that suit those limits), and do a quick fly over them, to end adjusting with single steps if I am undecided between two of the power based keys. Or use a rectangle select, followed by a single readjust to reduce the jaggies, if I need to fit something.

[...]

In my earlier mail I presented a possible compromise between homogenous zooming (I hope I made the advantages of that approach clear) and 1:x based zooming. I think it keeps best of both worlds and would like to ask, that alternative proposals have a careful discussion of advantages vs. backdraws against this.

Minus the 2:45 and 2:3 ones, it matches a perfect 1:n, like one of my suggestions. I pushed 2:45 to 1:22 and updated my patch on my site (seems I have not managed to get rid of those two phrases yet). Also attached.

http://www.infernal-iceberg.com/gimp/gimpdisplayshell-scale.c-floatfixed.diff

GSR
Index: app/display/gimpdisplayshell-scale.c =================================================================== RCS file: /cvs/gnome/gimp/app/display/gimpdisplayshell-scale.c,v retrieving revision 1.66
diff -u -p -r1.66 gimpdisplayshell-scale.c --- app/display/gimpdisplayshell-scale.c 11 Jan 2004 12:55:45 -0000 1.66 +++ app/display/gimpdisplayshell-scale.c 18 Jan 2004 18:18:48 -0000 @@ -72,32 +72,124 @@ gimp_display_shell_scale_zoom_fraction ( gint *scalesrc, gint *scaledest) {
- gdouble ratio;
+ /* Presets array stores the zoom by 2, to be able to have 1.5 */ + /* The sequence is an approximation to N+1 = N*sqrt(2) */ +#define NUM_PRESETS (16)
+ const gint presets[NUM_PRESETS] = { + 2, 3, 4, 6, 8, 12, 16, 22, 32, 44, 64, 90, 180, 256, 360, 510 + };
+ gint src, dest;
+ gint nratio;
+ gfloat ratio;
+ gboolean swapped = FALSE;
+ gint shift, mid;
+ gint low = 0;
+ gint high = (NUM_PRESETS-1);

g_return_if_fail (scalesrc != NULL); g_return_if_fail (scaledest != NULL);
- ratio = (double) *scaledest/ *scalesrc; + src = *scalesrc;
+ dest = *scaledest;

- switch (zoom_type)
+ if (! ((zoom_type == GIMP_ZOOM_IN) || (zoom_type == GIMP_ZOOM_OUT))) {
- case GIMP_ZOOM_IN:
- ratio *= G_SQRT2;
- break;
-
- case GIMP_ZOOM_OUT:
- ratio /= G_SQRT2;
- break;
-
- default:
- *scalesrc = CLAMP (zoom_type % 100, 1, 0xFF); - *scaledest = CLAMP (zoom_type / 100, 1, 0xFF); - return;
- break;
+ /* zoom_type is an "encoding" of desired zoom */ + src = CLAMP (zoom_type % 100, 1, 0xFF); + dest = CLAMP (zoom_type / 100, 1, 0xFF); + }
+ else if ((src == 1) && (dest == 1)) + {
+ /* Flip point, manual handling, the table is unable to handle this */ + switch (zoom_type)
+ {
+ case GIMP_ZOOM_IN:
+ /* 1:1 -> 3:2 */
+ dest = 3;
+ src = 2;
+ break;
+
+ case GIMP_ZOOM_OUT:
+ /* 1:1 -> 2:3 */
+ dest = 2;
+ src = 3;
+ break;
+ }
+ }
+ else
+ {
+ /* Handling by presets, requires scaling ratio by 2 to fit table */ + ratio = ((gfloat) dest) / ((gfloat) src); + if (ratio < 1.0)
+ {
+ swapped = TRUE;
+ ratio = (2.0 / ratio);
+ }
+ else
+ {
+ ratio *= 2.0;
+ }
+
+ /*
+ Readjust into N:2 (or 2:N) erring in the right side so + direction is kept and jump is only one step + swapped FALSE: 2 3 4 6 8 + IN -> floor + OUT ceil + OUT nratio) + high = mid - 1;
+ else
+ low = mid + 1;
+ }
+
+ /* Unscale, making sure all values are in range */ + mid += shift;
+ mid = CLAMP (mid, 0, (NUM_PRESETS-1)); + dest = presets[mid];
+ if ((dest % 2) == 0)
+ {
+ src = 1;
+ dest = CLAMP ((dest/2), 1, 0xFF); + }
+ else
+ {
+ src = 2;
+ dest = CLAMP (dest, 1, 0xFF); + }
}

- /* set scalesrc and scaledest to a fraction close to ratio */ - gimp_display_shell_scale_calc_fraction (ratio, scalesrc, scaledest); + if (swapped)
+ {
+ *scalesrc = dest;
+ *scaledest = src;
+ }
+ else
+ {
+ *scalesrc = src;
+ *scaledest = dest;
+ }
}

void

On Sun, Jan 18, 2004 at 07:24:01PM +0100, GSR - FR wrote:

-O2
-O2 -ffloat-store
-O2 -fno-strict-aliasing
-O2 -ffloat-store -fno-strict-aliasing

Just to clarify, -fno-strict-aliasing works around bugs in existing code, while -ffloat-store ensures that rounding is done at every step necessary to get exact ieee 754 semantics.

declared const, and still the only way is -O0.

There are not too many options here:

- this is a bug in the code - this is the bug in gcc
- this is a bug in the algorithm

If it's not a gcc bug (which is possible but not necessarily probable), thens ee below for some ideas on what this might have caused.

Getting different values cos the compiler decides you can go with different data size depending if it keeps all or not in CPU is not

It's still legal, if you define "legal" as following the standards.

It's also not much of a problem usually since you just get extra precision and less rounding, which only a few algorithms have a problem with, and these usually fit into the "designed for specific fp implementations" class.

It's also, fortunately, an x86-only-problem, as it's only a big speed hit on x86.

As for workarounds for this, you can either use -ffloat-store or setfpucw, in which case you lose the ability to do double precision.

However, since -ffloat-store doesn't fix the problems, it could be that the compiler does some unexpected (but legal) transformations.

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 :)

Unless you are certain that this isn't caused by a real gcc bug (usually, compiling with different major versions of the compiler is a good indication in favour or against it, depending on the outcome, as the same bug in gcc-2.95 and gcc-3.x is a rare thing), you might want to chekc your code for constructs where the limited precision of floating point values makes a difference.

This is just a hint, this does not mean that there is a bug there, but floating point values, as you of course know, have their problems that real numbers don't have.

(BTW, gdoubles and doubles etc. are not different, so there is no need to bother with testing one set against the other).

pcg@goof.com ( 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?

GSR - FR (famrom@infernal-iceberg.com) wrote:

Simon.Budig@unix-ag.org (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) {
gint i, 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 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

Simon.Budig@unix-ag.org (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 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

[restricting this to gimp-devel, since this is purely technical stuff]

GSR - FR (famrom@infernal-iceberg.com) wrote:

Simon.Budig@unix-ag.org (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 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

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 (famrom@infernal-iceberg.com) wrote:

Simon.Budig@unix-ag.org (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

On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig 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.

On Tue, Jan 20, 2004 at 04:13:19AM +0100, Marc A. Lehmann wrote:

On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig 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.

Well, the bulk of the code in gimp that causes warnings is stuff like:

void foo (void **p);

void bar (void) {
int *i;
foo ((void **) &i);
}

While it does break the letter of the law wrt aliasing rules, are there any assumptions that the compiler can legally make that would cause problems?

-Yosh

On Tue, Jan 20, 2004 at 01:24:15AM -0800, Manish Singh wrote:

On Tue, Jan 20, 2004 at 04:13:19AM +0100, Marc A. Lehmann wrote:

On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig 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.

Well, the bulk of the code in gimp that causes warnings is stuff like:

void foo (void **p);

void bar (void) {
int *i;
foo ((void **) &i);
}

does this count the things that you cannot do? it would be very silly to tie a process up with this sort of thing. this list is infinite.

While it does break the letter of the law wrt aliasing rules, are there any assumptions that the compiler can legally make that would cause problems?

does gcc do this? count up things that it is not allowed to do? will the compiler need to be rewritten?

carol

I've tried Simons Patch, and it seemed very nice for me. Of course I am innoi position to word out what should and should not be commited, but from a user point of view, it is nice.

Unfortunately I could not check GSR's patch because of compiling issues.

Regards,

JS
->

On Monday 19 January 2004 23:22, Simon Budig wrote: (...)

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

On Tue, Jan 20, 2004 at 01:24:15AM -0800, Manish Singh wrote:

Well, the bulk of the code in gimp that causes warnings is stuff like:

void foo (void **p);

void bar (void) {
int *i;
foo ((void **) &i);
}

While it does break the letter of the law wrt aliasing rules, are there any assumptions that the compiler can legally make that would cause problems?

Well, troubling to me would be the fact that a int is not the same as a void *, so this very example is a bit strange and could likely cause problems on 64-bit (or else) architectures, but that is, of course, not the main point.

I don't know the real case this is based on, but I'd wonder what this code is supposed to do then. Please note that the warning will not happen when you cast to a void *, since the pointers might alias then.

Legally, the compiler could cache the contents of i in a register before and after the call, because foo is not allowed to change it's value. (And I might guess that foo will not do that, but it's equally hard to see this as a compiler as it is for a human, so the warning is IMnsO justified).

It's unlikely that this will happen with gcc t make much of a difference in generated code with gcc, as it is not very good at taking advantage of (no-) aliasing yet, but this is a hot area in gcc, since exploiting aliasing rules allow a great deal of optimizations in typical numerical code.

On Tue, Jan 20, 2004 at 02:51:17PM +0100, Marc A. Lehmann wrote:

On Tue, Jan 20, 2004 at 01:24:15AM -0800, Manish Singh wrote:

Well, the bulk of the code in gimp that causes warnings is stuff like:

void foo (void **p);

void bar (void) {
int *i;
foo ((void **) &i);
}

While it does break the letter of the law wrt aliasing rules, are there any assumptions that the compiler can legally make that would cause problems?

Well, troubling to me would be the fact that a int is not the same as a void *, so this very example is a bit strange and could likely cause problems on 64-bit (or else) architectures, but that is, of course, not the main point.

You misread. To explain further:

void set_null (void **p) {
*p = NULL;
}

void foo (void)
{
int *i;
set_null ((void **) &i);
}

Which basically sets i = NULL. I don't see how this can be a problem on a 64-bit architectures, since pointers to all types are the same size.

gimp actually only does this with external functions, like:

void g_object_add_weak_pointer (GObject *object, gpointer *weak_pointer_location);

or

gboolean g_module_symbol (GModule *module, const gchar *symbol_name, gpointer *symbol);

Perhaps the API should be fixed, I dunno.

I don't know the real case this is based on, but I'd wonder what this code is supposed to do then. Please note that the warning will not happen when you cast to a void *, since the pointers might alias then.

Sure, I know ways of working it around it. My preferred fix is not to cast to a void *, but use a temporary void * and assign back, since that adds some type safety instead of casting.

Legally, the compiler could cache the contents of i in a register before and after the call, because foo is not allowed to change it's value. (And I might guess that foo will not do that, but it's equally hard to see this as a compiler as it is for a human, so the warning is IMnsO justified).

Ah, that answers my question, thanks.

It's unlikely that this will happen with gcc t make much of a difference in generated code with gcc, as it is not very good at taking advantage of (no-) aliasing yet, but this is a hot area in gcc, since exploiting aliasing rules allow a great deal of optimizations in typical numerical code.

Well, one problem is that flagging every violation like this makes people tend to ignore the warning, which means real problems which affect gcc's alias analysis *now* are likely to be overlooked, or heavy handed solutions like -fno-strict-aliasing put in. It'd be much nicer if this warning didn't trigger for function parameters (except with -pedantic) until gcc was closer to doing the alias analysis that would manifest a problem.

As it stands, right now the warning mainly confuses people. It doesn't help that the aliasing rules aren't spelled out anywhere in the gcc docs. I was actually skeptical that gcc might be buggy in this regard, until I dug up the appropriate bits of the standard that say what's going on.

-Yosh

Joao S. O. Bueno (gwidion@mpc.com.br) wrote:

I've tried Simons Patch, and it seemed very nice for me. Of course I am innoi position to word out what should and should not be commited, but from a user point of view, it is nice.

There are two things I'd like to know.

As you know Gimp avoids opening too big image windows when loading an image. Right now the size of the image area is restricted to 0.75 * screen dimensions. This of course is perfectly Ok.

However, I'd like to know which of the two following behaviours is preferrable in case of an image being too big for the screen:

a) open the image as big as possible (zoom-to-fit to a window about 0.75 * screen dimensions), this roughly is the behavior of current CVS.

b) open the image in the next smaller zoom preset (which would result in image windows smaller than the 0.75 * screen dimensions, but would have nice ratios) (since CVS does not yet really have any zoom presets its hard to compare...)

Also I'd like to know if the zoom steps around 100% are fine grained enough. Homogenous zooming right now is implemented with a factor of 2^(1/2) (from 100% to 200% in two steps), but 2^(1/3), 2^(1/4) would work as well (three, resp. four steps from 100% to 200%) and give finer grained steps.

Opinions?

Thanks, Simon

Simon Budig (Simon.Budig@unix-ag.uni-siegen.de) wrote:

a) open the image as big as possible (zoom-to-fit to a window about 0.75 * screen dimensions), this roughly is the behavior of current CVS.

b) open the image in the next smaller zoom preset (which would result in image windows smaller than the 0.75 * screen dimensions, but would have nice ratios) (since CVS does not yet really have any zoom presets its hard to compare...)

Oops, sorry I mixed that up. Right now Gimp-CVS uses the old zoom steps when opening a new image (kind of behaviour b). My patch implements a) here and I got confused with the two different GIMPs... :-)

Bye, Simon

On Wednesday 21 January 2004 12:27, Simon Budig wrote:

Joao S. O. Bueno (gwidion@mpc.com.br) wrote:

I've tried Simons Patch, and it seemed very nice for me. Of course I am innoi position to word out what should and should not be commited, but from a user point of view, it is nice.

There are two things I'd like to know.

As you know Gimp avoids opening too big image windows when loading an image. Right now the size of the image area is restricted to 0.75 * screen dimensions. This of course is perfectly Ok.

However, I'd like to know which of the two following behaviours is preferrable in case of an image being too big for the screen:

a) open the image as big as possible (zoom-to-fit to a window about 0.75 * screen dimensions), this roughly is the behavior of current CVS.

b) open the image in the next smaller zoom preset (which would result in image windows smaller than the 0.75 * screen dimensions, but would have nice ratios) (since CVS does not yet really have any zoom presets its hard to compare...)

Hmm...
Actually, 0.75 is sometimes boring, when the whole image would fit in, say, 90% of the screen, and it shows up zoomed out.

regarding your specific question, it would not be nice if the GIMP openned an image in a zoom factor that once changed could not get easily reproduced. So the answer is (b).However, if you could make it in a way that if the next bigger zoom ratio (in the 2^(1/2) steps you use) would be no larger than 80% or maybe 85% of the screen it would be the one used.

On the other hand, I was not around when the choice for 75% was made, and there may be strong motives for that.

Also I'd like to know if the zoom steps around 100% are fine grained enough. Homogenous zooming right now is implemented with a factor of 2^(1/2) (from 100% to 200% in two steps), but 2^(1/3), 2^(1/4) would work as well (three, resp. four steps from 100% to 200%) and give finer grained steps.

Yes, it seens just ok. I would not like to have to hit '+' four times to get a image twice as large.

Now let's see what others have to say.

Opinions?

Thanks,
Simon

Regards,

JS
->

Hi,

"Joao S. O. Bueno" writes:

Actually, 0.75 is sometimes boring, when the whole image would fit in, say, 90% of the screen, and it shows up zoomed out.

regarding your specific question, it would not be nice if the GIMP openned an image in a zoom factor that once changed could not get easily reproduced. So the answer is (b).However, if you could make it in a way that if the next bigger zoom ratio (in the 2^(1/2) steps you use) would be no larger than 80% or maybe 85% of the screen it would be the one used.

On the other hand, I was not around when the choice for 75% was made, and there may be strong motives for that.

IIRC, 75% was choosen rather arbitrarily and I agree that it would make sense to use 85% or even 90% instead and choose the closest sane display ratio below.

Sven

Hello.

More in-between steps in the logaritmic zoom (...,2:1,1:1,1:2, 1:4,...) would be nice, but nothing fancy like more steps around 1:1 is not needed here.

There are more important problems relating to the zoom and resolution: I scanned a drawing and wanted to complete it with GIMP. After I had zoomed the large image, largest pencil was too tiny for drawing.

This gives an idea that GIMP could have a tool which computes the scale ratio required for matching the scanned pencil size with the size of the selected pencil. The tool could work this way: (1) select the pencil, (2) start the tool, (3) zoom the image until the selected pencil size matches the scanned pencil size, (4) start scale operation which takes the zoom ratio as scale ratio. That would require that GIMP can draw the outline circle (say) of the pencils.

Does not solve the underlying problems of GIMP, but is better than nothing.

Regards,
Juhana

Hi,

Juhana Sadeharju writes:

There are more important problems relating to the zoom and resolution: I scanned a drawing and wanted to complete it with GIMP. After I had zoomed the large image, largest pencil was too tiny for drawing.

Any particular reason you did not press the "New" button in the brush dialog to obtain a larger brush?

Sven

This is my first post here.

top flight (topflight444@yahoo.com) wrote:

This is my first post here.? Is the proper protocol to 1) post here to the mail lists?
2) put on the bug list?
3) both?
?

Well, since we are in a discussion here a post on the bug list might be a bit too early. But yes, a enhancement request in bugzilla will definitely get a response, but on the zooming behaviour there are enough open bugs right now :)

In reference to the earlier discussion about uniform zooming scale factors, why not let the user choose his own (reasonable) scale factor in preferences? It could be set to sqrt(2) by default. The code below?rounds to the nearest multiple of the?factor.? I think it is an elegant solution which gives a lot of power to the user.

Well, we have a lot of preferences already and one can have too much degrees of freedom. When I brought up different sets of zoom presets available in the preferences, some people were complaining, that preferences are just a sign of a lack of descision competence :-)

[ code snipped for arbitrary factors ]

As you might have seen in the earlier discussion, for some people it is very important, to get sane ratios like 1:x as magnification factors. Your approach of course would work, but usually result in ugly fractions. The list of fractions from the earlier Mails were the result of a compromise, a move back to "real floats" is not an option.

Personally I believe that only factors based on the n'th roots of two are reasonable choices, since we usually want to have the double, quadruple etc. sizes of the images in the list of zoom factors.

For a short time we had something based on the golden mean in CVS, and it really felt clumsy, because it was so hard to hit the powers of two as magnification factors...

sqrt(2) gives us two steps between each doubling of the size, and it seems to be fine enough. I might experiment later with 2**(1/3), but that isn't really urgent now.

Bye, Simon