in reply to Tk Zooming Fractal Problems

I doubt you will find a solution for this, so this is just a quick observation. :-) If you were just trying to zoom a static image, it wouldn't be too hard, but since you are recomputing the fractal after zooming, it only takes 2 or 3 clicks to quickly drive the cpu into 99% usage, if you expand the canvas.

In your code, you don't enlarge the $c_size to account for the *2 scaling, so the fractal moves right off the canvas. If you scale the $canvas with $c_size *=2; in the sub, you quickly drive the cpu into unusability.

You might want to keep the original fractal, and just adjust the scollregion to make it move to appear to center it where you mouse click. In that case it may be better to write the fractal to an image first.


I'm not really a human, but I play one on earth. Cogito ergo sum a bum

Replies are listed 'Best First'.
Re^2: Tk Zooming Fractal Problems
by Melly (Chaplain) on Dec 06, 2006 at 18:29 UTC

    Hmm, unless I've misunderstood something, I'm not sure I agree - my main cpu worry is the amount of lines I'm throwing at the canvas. As far as the main computing goes, since I don't increase (yet:) the number of iterations at different scales, the number of calculations is fixed.

    Also, my code worked fine when I didn't try to center the fractal on the location clicked on - i.e. it just zoomed in.

    In theory, all I've got to do is adjust the start points for the calculation to see a different area, and it *almost* works with the current code, but something's going screwy. I think what I need to do is to remove the mandlebrot from the equation (sic), and just get some debugging output... sigh...

    map{$a=1-$_/10;map{$d=$a;$e=$b=$_/20-2;map{($d,$e)=(2*$d*$e+$a,$e**2 -$d**2+$b);$c=$d**2+$e**2>4?$d=8:_}1..50;print$c}0..59;print$/}0..20
    Tom Melly, pm@tomandlu.co.uk
      Well I played with your code, and what I think you need to do is reset the canvas size and scrollregion when you call the sub. The way your current code works, you make the fractal bigger, but never adjust the canvas size to accomodate it. This is as far as I got, before the cpu usage made me give it up. I added scrollregions, adjust $c_size with $scale, and set the $scale to 1.2 to troubleshoot easier. Anyways, click this a few times and watch what happens, compared to your original script.
      #!/usr/bin/perl use warnings; use strict; use Tk; my $c_size = 100; my $scale = 1; my $mw = MainWindow -> new; my $canvas = $mw -> Scrolled('Canvas', -height=>$c_size, -width=>$c_size, -scrollregion => [0,0,$c_size,$c_size] )-> pack(-expand=>1 ,-fill=>'both'); $canvas -> Tk::bind('all', '<ButtonPress-1>' => \&MakeMan); &MakeMan(); MainLoop; sub MakeMan(){ my ($e, $canv_x, $canv_y)=(0,$c_size/2,$c_size/2); if($scale > 1){ $e = $canvas -> XEvent; $canv_x = $e->x; $canv_y = $e->y; } my $icount = 1; $c_size *= $scale; #problem here... my $i = -2/$scale + (($canv_y-($c_size/2)) / ($c_size/$scale));# + $ +lasti; my $rgb; while($icount <= $c_size){ #... and here... my $r = -2/$scale + (($canv_x-($c_size/2)) / ($c_size/$scale));# + + $lastr; my $rcount = 1; while($rcount <= $c_size){ my $tr = $r; my $ti = $i; $rgb = '#000000'; for my $n(1..15){ ($tr, $ti) = (($tr ** 2) - ($ti ** 2) + ($r), (2 * $tr * $ti) ++ ($i)); if((($tr * $tr) + ($ti * $ti)) > 4){ $rgb = '#ffffff'; last; } } $canvas -> createLine($rcount, $icount, $rcount+1, $icount, -fil +l => $rgb, -width => 1); $rcount ++; $r += (4/$scale)/$c_size; } $icount ++; $i += (4/$scale)/$c_size; } $scale = $scale * 1.2; $canvas->configure(-scrollregion=>[0,0,$c_size,$c_size]); $canvas->update; }

      I'm not really a human, but I play one on earth. Cogito ergo sum a bum