[Gimp-developer] Re: [Gimp-user] Re: Alternative zoom algorithm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



GSR - FR (famrom@xxxxxxxxxxxxxxxxxxxx) wrote:
> Simon.Budig@xxxxxxxxxxx (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 <- 200:
http://www.infernal-iceberg.com/gimp/gimpdisplayshell-scale.c-dirty.diff
---------

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.

-- 
      Simon.Budig@xxxxxxxxxxx       http://www.home.unix-ag.org/simon/

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux