| Summary: | Reduce zooming increment | ||
|---|---|---|---|
| Product: | [Applications] gwenview | Reporter: | Ettore Atalan <atalanttore> |
| Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | avatar, de.techno, evgom.sid, h.klene, landis.reed, mathieu, nate, private_lock, simonandric5, thomas |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | All | ||
| URL: | http://forum.kde.org/viewtopic.php?f=213&t=111774 | ||
| Latest Commit: | https://commits.kde.org/gwenview/e014d581e52b04dfbf1b576abe84962910ab5f6a | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
Patch to fix huge zoom's increment/decrement
original calc table calc table at 33% calc table at 35% |
||
|
Description
Ettore Atalan
2012-09-30 19:15:05 UTC
*** 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! |