Logo by Sockratease - Contribute your own Logo!

END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Visit us on facebook
 
*
Welcome, Guest. Please login or register. March 29, 2024, 04:37:24 PM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: [1]   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: feature request: mouse scroll zooming shouldn't recenter the view  (Read 473 times)
Description: instead everything zooms around where the mouse is
0 Members and 1 Guest are viewing this topic.
claude
Fractal Bachius
*
Posts: 563



WWW
« on: December 17, 2014, 11:12:30 PM »

I'd really love it if (scroll wheel especially) zooming happened around the mouse cursor, instead of recentering the view each time. Otherwise it's too easy to scroll too much and go off-center, meaning having to backtrack and retry.

Here's some code I use in mightymandel to do that using libmpfr for arbitrary precision floating point:

Code:
void view_zoom(struct view *v, mpfr_t x, mpfr_t y, double z) {
  double g = pow(sqrt(0.5), z);
  mpfr_mul_d(v->radius, v->radius, g, MPFR_RNDN);
  mpfr_prec_t p = fmax(53, 16 - log2(mpfr_get_d(v->radius, MPFR_RNDN)));
  mpfr_prec_round(v->centerx, p, MPFR_RNDN);
  mpfr_prec_round(v->centery, p, MPFR_RNDN);
  mpfr_t t;
  mpfr_init2(t, p);
  mpfr_mul_d(t, x, (1 - g), MPFR_RNDN);
  mpfr_mul_d(v->centerx, v->centerx, g, MPFR_RNDN);
  mpfr_add(v->centerx, v->centerx, t, MPFR_RNDN);
  mpfr_mul_d(t, y, (1 - g), MPFR_RNDN);
  mpfr_mul_d(v->centery, v->centery, g, MPFR_RNDN);
  mpfr_add(v->centery, v->centery, t, MPFR_RNDN);
  mpfr_clear(t);
}

Untested double precision version for ease of reading and understanding:

Code:
// x, y are coordinates where the zoom request was made (mouse)
// they are M-set coordinates, not window coordinates
// z is a zoom amount, like +1 or -1  (0 would recenter the view)
void view_zoom(struct view *v, double x, double y, double z) {
  double g = pow(sqrt(0.5), z); // zoom factor - could instead supply g as an argument
  v->radius *= g
  v->centerx = g * v->centerx + (1 - g) * x
  v->centery = g * v->centery + (1 - g) * y
}
Logged
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #1 on: December 18, 2014, 04:13:01 PM »

Whenever i see raw mpfr code i cant help but think



 afro

if you use C++ there is this really nice wrapper that makes using mpfr no more painful than using built-in types.

http://www.holoborodko.com/pavel/mpfr/

with move semantics and all the nice stuff that C++11/14 offers (which this wrapper also makes use of), there seems to be little reason to keep yourself shackled to C, especially if it means writing tons of assembly-like mpfr code.  angel

(that wrapper is also integrated with boost's arbitrary precision stuff, if you want to get the same functionality through boost)
Logged
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #2 on: December 18, 2014, 04:45:30 PM »

Thanks, I'll give it a look - one problem I had in previous C++ experiments (mainly with Boost) seems to be solved by this one: http://www.holoborodko.com/pavel/mpfr/#internals
Quote
Other libraries calculate intermediate results with the precision of final variable or round them to some not obvious to user precision which is independent from precision of arguments as well as from precision of final variable. This could lead to a significant reduction in the accuracy of the final result.

The other issue is having to write my own complex number class (std::complex (per the spec) only works with built-in types, and my attempts to use it with Boost gave me random NaNs all over.. something like default value for double is 0 and default for mp_real is NaN, so initializing a complex from a real made the imag part NaN - not fixable in my code, because some occurences were in library code).
Logged
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #3 on: December 18, 2014, 07:38:44 PM »

hmm, i have been using mpreal with std::complex and have not had any issues.  everything works including things like std::abs() to get the magnitude.  std::complex has float, double, and long double specializations in addition to the template version, which has worked just fine for me in combination with mpreal and another custom type.  you are saying you can only initialize the real element of a std::complex?  i think it is new in C++11 but you can brace-initialize std::complex like std::complex<mpreal> foo { "2.3", "4.7" };  and you can also use similar syntax in assignment, like foo = { a, b };  i think std::complex<type> foo(a, b); works for initialization also.

i just ran a test, not initializing a std::complex<mpreal>, and both elements initialize to zero by default
Logged
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #4 on: December 18, 2014, 08:40:23 PM »

you are saying you can only initialize the real element of a std::complex?

i just ran a test, not initializing a std::complex<mpreal>, and both elements initialize to zero by default

I meant initializing only real part, with imag left unspecified.

When I tried (with boost, some time ago - maybe as long as a year ago), it initialized to NaN which messed everything up.

Will retry soon, asm-style mpfr is not much fun!
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #5 on: December 19, 2014, 01:23:04 PM »

I'd really love it if (scroll wheel especially) zooming happened around the mouse cursor, instead of recentering the view each time. Otherwise it's too easy to scroll too much and go off-center, meaning having to backtrack and retry.
I don't have a mouse, I am only using the touch-pad on my laptop.
Anyway, the zoom is performed on the position of the mouse pointer, which I would assume is "around the mouse cursor".
From what I can understand it does exactly what you are suggesting.
But since you suggested that at all, I guess I am wrong.
Would you like it to zoom into the center of the window when the mouse wheel is used?
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #6 on: December 19, 2014, 03:27:53 PM »

he means making the center of the zoom where the mouse cursor is, without making the zoom center the center of the image.  personally i hate that behavior when i encounter it in a fractal zoomer, and suspect most do.
Logged
Adam Majewski
Fractal Lover
**
Posts: 221


WWW
« Reply #7 on: December 19, 2014, 04:19:34 PM »

... there is this really nice wrapper that makes using mpfr no more painful than using built-in types.

http://www.holoborodko.com/pavel/mpfr/


If you think about mpfr wrapper then what about

http://multiprecision.org/

"Gnu Mpc is a C library for the arithmetic of complex numbers with arbitrarily high precision and correct rounding of the result."

?
Logged
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #8 on: December 19, 2014, 05:45:28 PM »

i could never tell by looking at their website or their manual what mpc actually does different / in addition to mpfr.  in any case, its still the same sort of horrible C interface.
Logged
Dinkydau
Fractal Senior
******
Posts: 1616



WWW
« Reply #9 on: December 19, 2014, 06:33:05 PM »

Another description that might help: the idea is that the point which is zoomed in on remains where it is on screen. Currently it moves to the center. I prefer that it doesn't do that with the scroll wheel either. With clicking I think it's okay, though.
Logged

claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #10 on: December 19, 2014, 06:40:10 PM »

Ooh, mpc looks good - if there's a Debian package I'll switch to using it right away.  My own complex wrapper is so ugly, you have to pass in re/im parts separately, AND all the temporaries the function needs (to avoid repeated allocations/deallocations in the inner loop, but maybe mpfr/mpc allocation isn't so expensive?).  Example from my wrapper:

Code:
extern void cmpfr_mul(mpfr_t r_re, mpfr_t r_im, const mpfr_t x_re, const mpfr_t x_im, const mpfr_t y_re, const mpfr_t y_im, mpfr_t t0, mpfr_t t1, mpfr_t t2, mpfr_t t3, mpfr_rnd_t rnd) {
  mpfr_mul(t0, x_re, y_re, rnd);
  mpfr_mul(t1, x_im, y_im, rnd);
  mpfr_mul(t2, x_re, y_im, rnd);
  mpfr_mul(t3, x_im, y_re, rnd);
  mpfr_sub(r_re, t0, t1, rnd);
  mpfr_add(r_im, t2, t3, rnd);
}

Just wish the Haskell bindings for mpfr (rounded by ekmett on github) were released already, so I could use a nicer language than C or C++!

EDIT:
complex mpc beats real mpfr alone when you need advanced functions - implementing complex exp/log/trig/hyp functions isn't that hard, but it's boring.

and it's in debian

Code:
Package: libmpc-dev                     
State: not installed
Multi-Arch: same
Version: 0.9-4
Priority: extra
Section: libdevel
Maintainer: Laurent Fousse <lfousse@debian.org>
Architecture: amd64
Uncompressed Size: 265 k
Depends: libmpc2 (= 0.9-4), libmpfr-dev, libgmp-dev
Breaks: libmpc-dev (!= 0.9-4)
Replaces: libmpc-dev (< 0.9-4)
Description: multiple precision complex floating-point library development package
 MPC is a portable library written in C for arbitrary precision arithmetic on complex numbers providing correct rounding. For the time being, it contains
 all arithmetic operations over complex numbers, the exponential and the logarithm functions, the trigonometric and hyperbolic functions.
 
 Ultimately, it should implement a multiprecision equivalent of the ISO C99 standard.
 
 It builds upon the GNU MP and the MPFR libraries.
Homepage: http://www.multiprecision.org/mpc/
« Last Edit: December 19, 2014, 06:43:43 PM by claude » Logged
Pages: [1]   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Feature Removal Request Mandelbulb 3d Sockratease 6 1589 Last post January 03, 2012, 10:25:15 AM
by Teena
Another feature request... Mandelbulb 3d TsarveK 4 1572 Last post February 26, 2012, 11:53:43 PM
by Jesse
Yet Another Feature Request! feature request Sockratease 4 1854 Last post July 31, 2012, 02:52:25 AM
by toxic-dwarf
Fragmentarium feature request Fragmentarium JosLeys 14 2542 Last post September 06, 2015, 09:33:34 PM
by 3dickulus
version 1.3.12 zoom with mouse scroll wheel crash Mandel Machine istinn 9 3089 Last post January 08, 2015, 01:34:01 AM
by Botond Kósa

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.295 seconds with 26 queries. (Pretty URLs adds 0.014s, 2q)