After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 124073 - Exotic zoom ratios in 1.3.*
Exotic zoom ratios in 1.3.*
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
1.x
Other All
: Normal normal
: 2.0
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2003-10-07 22:51 UTC by eric_wmaker
Modified: 2004-01-15 15:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to use sqrt(2) but doesn't address the other issue pointed out (1.28 KB, patch)
2004-01-10 15:50 UTC, Sven Neumann
none Details | Review

Description eric_wmaker 2003-10-07 22:51:02 UTC
I notice that when I use the zoom tool, I get really exotic zoom ratios
like 67:189 for example(see View>Zoom).  And that's fine, but if i then try
to use the zoom keyboard shortcut, it zooms in *really* small increments.

Sven commented, "The function that is called for the key shortcuts could be
made smarter."
Comment 1 Sven Neumann 2003-10-08 00:18:22 UTC
Right now when the user zooms in one step the nominator is
incremented, on zoom out, the denominator is incremented. It would
probably be better to bind the zoom factor to the displayed area.
Comment 2 Dave Neary 2003-11-25 13:21:08 UTC
How about limiting the size of the numerator to (say) 50, and
adjusting as required to fit into that afterwards? So 67:189 would get
mapped to 18:50, which would scale a bit better using the
numerator/denominator idea.

Alternatively, we have the scale work on the percentages, say that
zoom in halves the percentage, and zoom out doubles it? (or vice
versa, I haven't really thought about it).

Cheers,
Dave.
Comment 3 Daniel Rogers 2003-11-25 16:23:21 UTC
I agree, binding to the displayed area is better.  If fact what I
would like to see is a constant fractional change in area per small
change in the scroll bar.  That would have for a very perceptually
smooth change in zoom, as opposed to now where the large zoom levels
change _very_ quickly and the small zoom levels change very slowly.
Comment 4 Sven Neumann 2003-11-25 16:48:43 UTC
That's exactly what I was suggesting when I said that the callback
could be smarter. Limiting the numerator wouldn't be smart however but
the zoom step should be based on the area change; probably using the
golden section.
Comment 5 Pedro Gimeno 2003-11-30 22:12:53 UTC
I'd also suggest to simplify the fraction whenever possible, so that 
the increments are not so small. So, a zoom ratio of, say, 36:18 
would become 2:1; in general it would start behaving in a more usual 
way more quickly.
Comment 6 Sven Neumann 2003-11-30 22:59:29 UTC
*** Bug 128241 has been marked as a duplicate of this bug. ***
Comment 7 Sven Neumann 2003-11-30 23:01:02 UTC
The problem mentioned in bug #128241 (checkerboard alignment with the
pixel grid) should be taken into consideration when addressing this
problem. 
Comment 8 Dave Neary 2004-01-09 21:15:33 UTC
Fixed in CVS.

2004-01-09  Dave Neary  <bolsh@gimp.org>
 
        * app/display/gimpdisplayshell-scale.c: Modify behaviour of
        the magnify tool to always change the zoom factor by the
        golden ratio, rather than modify the numerator and denominator
        directly. Fixes bug #124073.
 
I did not do anything here which addresses bug #128241.
Comment 9 Sven Neumann 2004-01-10 15:24:28 UTC
I suggested the use of the golden ratio myself but I have to say that
I am not happy with the new behaviour. It is definitely an improvement
but the current algorithm leads to strange zoom ratios. I would like
to suggest that we use the factor sqrt(2) instead (or rather G_SQRT2).
This would mean that zooming in one step reduces the displayed area by
a factor of 2. The series of display ratios would then look like this:

 100% -> 141% -> 200% -> ...
 100% -> 70%  ->  50% -> ...

Unfortunately it doesn't work exactly like this. The actual result is:

 100% -> 141% -> 199%

We should consider to change gimp_display_shell_scale_calc_fraction()
so that it prefers "standard" display ratios with small nominators and
denominators.
Comment 10 Dave Neary 2004-01-10 15:44:57 UTC
I agree. Did some zooming, don't like phi. sqrt(2) sounds like a good
idea. Will look at it today.

Dave. 
Comment 11 Sven Neumann 2004-01-10 15:50:33 UTC
Created attachment 23202 [details] [review]
patch to use sqrt(2) but doesn't address the other issue pointed out
Comment 12 Simon Budig 2004-01-10 23:46:05 UTC
tackled this in CVS. I believe the behaviour has improved, but further
improvements seems possible.

2004-01-11  Simon Budig  <simon@gimp.org>

        * app/display/gimpdisplayshell-scale.c: calculate the
        fraction from the zoom ratio using continued fractions.
        This prefers smaller numbers in numerator/denominator.

        Adresses bug #124073, but does not completely fix it,
        since scaling up/down does not always result in the same
        ratios.
Comment 13 Simon Budig 2004-01-11 00:30:05 UTC
*twiddle* *twiddle*:

2004-01-11  Simon Budig  <simon@gimp.org>

        * app/display/gimpdisplayshell-scale.c: further tweaks.
        now excluding fractions where numerator*denominator > 200
        (only when both are > 1).
        This is a simple heuristic to exclude some absurd looking
        fractions.

        Also ensure that 1/ratio results in b:a, when ratio results
        in a:b.

        IMHO fixes bug #124073.
Comment 14 Dave Neary 2004-01-15 15:33:59 UTC
*** Bug 131563 has been marked as a duplicate of this bug. ***