Hi The current zooming increment (...-> 50% -> 100% -> 200% -> 300% -> 400% -> ...) is much too big. I would prefer 25% steps for each time pressing Ctrl & + or Ctrl & mouse wheel. Up to now the default zoom level is 100% and the next increment when zooming in by keyboard is already a doubling (200%) of the zoom level. Regards, Ettore Atalan
*** Bug 312621 has been marked as a duplicate of this bug. ***
*** Bug 285364 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
Please, fix it.
No one interested in fixing this?
This problem persists up to the latest Gwenview version.
Created attachment 96670 [details] Patch to fix huge zoom's increment/decrement I made a patch to fix the huge zoom's increment/decrement. Now the changes is 10%, I think it's a great value. Please test it.
*** Bug 378584 has been marked as a duplicate of this bug. ***
Thanks for the patch, Erick! Can you submit it to http://phabricator.kde.org/? As you can see, patches in bug reports tend to get lost. I'd really like to see this get in.
The patch is at https://phabricator.kde.org/D7972
Git commit e014d581e52b04dfbf1b576abe84962910ab5f6a by Nathaniel Graham. Committed on 21/10/2017 at 19:03. Pushed by ngraham into branch 'master'. Scroll wheel and touchpad zoom in smaller increments Summary: Change the zoom speed so that the scroll wheel and touchpad zoom behavior matches that of Inkscape and Krita: for more than 100%, the zoom is increased by sqrt(2); for less than 100%, the zoom is decreased by sqrt(0.5). In practice this means the following zoom levels: 35% → 50% → 71% → 100% → 141% → 200% → 283% → 400% → 566% → 800% This feels much more comfortable and offers more control compared to the current ever-accelerating zoom speed. Submitting this patch on behalf of Vangelis Tasoulas. Test Plan: Tested in KDE Neon. Works as advertised. Reviewers: #kde_applications, vtasoulas, lukas, gateau, rkflx Reviewed By: vtasoulas, rkflx Subscribers: ltoscano, anthonyfieroni, rkflx Differential Revision: https://phabricator.kde.org/D7972 M +19 -9 lib/documentview/documentview.cpp M +1 -0 lib/documentview/documentview.h https://commits.kde.org/gwenview/e014d581e52b04dfbf1b576abe84962910ab5f6a
May I ask, why you opt for these uneven numbers ... 71 is a prime number, so it'll guarantee distortion to most pictures. Yes, cubic algorithms do a wonderful job on photos, so nobody will notice. But charts and other graphics with straight lines still suffer. I suggest rounding to nearby easy rational numbers: x sqrt(2)^x rational value error ------------------------------------ -8 0,06 1/20 0,05 20,00% -7 0,09 1/10 0,10 -13,14% -6 0,13 3/20 0,15 -20,00% -5 0,18 1/5 0,20 -13,14% -4 0,25 1/4 0,25 0,00% -3 0,35 1/3 0,33 5,72% -2 0,50 1/2 0,50 0,00% -1 0,71 3/4 0,75 -6,07% 0 1,00 1/1 1,00 0,00% 1 1,41 3/2 1,50 -6,07% 2 2,00 2/1 2,00 0,00% 3 2,83 3/1 3,00 -6,07% 4 4,00 4/1 4,00 0,00% 5 5,66 6/1 6,00 -6,07% 6 8,00 8/1 8,00 0,00% 7 11,31 11/1 11,00 2,77% 8 16,00 16/1 16,00 0,00% The implementation could use a little lookup table for those values and compute sqrt(2)^x only if out of range, though I expect the zoom increment only really rarely exceeding the lookup range. But feel free to add more.
Any chance you can test with some non-photographic images to see if they distort in the way you're worried about? If so, please file a new bug requesting the rounding behavior you've mentioned, and put a link to that bug in this one so we can track it.
Created attachment 108493 [details] original calc table
Created attachment 108494 [details] calc table at 33%
Created attachment 108495 [details] calc table at 35%
I reworked the rational numbers a little in calc to make them symmetric both sides of zero and reduce the error a little. Next I took a screenshot of calc. (So please don't take them from my previous post and have a look at the screenshot instead). Then I watched that screenshot at 33% in gwenview blowing it up again with plasmas magnifier. Notice the slightly uneven distribution of cell hight, although the lines come out pretty clearly as lines. Next I changed to 35% in gwenview and applied the magnifier again. Now some of the lines get washed out (counting from the top 4-6 and 16-18), as they are stretched over two pixel. But overall I'm quite pleased, how the pictures came out. I had imagined this effect to be worse. So I guess, I could live with the current implementation.
Awesome, glad to hear it!