Fractal eXtreme New Version–Better Zoom Movies

While working on the Really Deep Fractal Zoom Movie – Much Faster project (240 times faster!) several updates were made to Fractal eXtreme in order to improve the creating of zoom movies. These improvements are now available as part of the 2.20 release. The summary of these improvements is:

  • A bug related to pixel guessing was fixed. On one test movie this fix gave an overall calculation speedup of over 25%!
  • Support for variable speed playback when converting zoom movies to AVI movies was added.
  • A bug that would occasionally cause crashes when saving a zoom movie was corrected.
  • A bug that would cause images wider than 4,096 pixels to not reload iteration data was fixed.
  • A bug that caused failures when creating zoom movies from fractals that were rotated 90 or 270 degrees was fixed.
  • The progress meter that appears when rendering a zoom movie has been improved. It is now horizontally sizeable, it has an option to pause rendering, and it has an option to bring up the status window for more details on what is happening.
  • The timers that track how much time has been spent rendering an image or a movie now stop counting when your machine goes into hibernation, which makes them a more accurate reflection of the total computing time.
  • Statistics about each frame rendered are now saved to a .fxz.log file in the same directory as the movie. This records how long each frame took to calculate, the total number of iterations, the percentage of pixels that were guessed, the precision, and more.
  • When you save a zoom movie as an AVI file it is now optional whether the resulting AVI will be played automatically.
  • The undo limit in FX was increased from 50 to 500.

As always the latest version of Fractal eXtreme is available at

And now some details…

Pixel guessing

As was briefly mentioned here a problem was found where one calculation stage was being serialized instead of parallelized. Fractal eXtreme relies heavily on ‘guessing’ of areas of constant iterations in order to improve performance. Sometimes 75-95% of pixels can be guessed and this can give a tremendous performance improvement. However it is important that this process never give incorrect results, so at the end of every frame FX scans over the image to see if any guesses might be wrong. Any guessed pixel that is not surrounded by eight identical pixels is deemed risky and is explicitly calculated.

Due to a logic flaw it turned out that all processors would recalculate the same pixel, and then move on to the next one, almost in lock step. That meant that this phase would run ‘n’ times slower than it should, where ‘n’ is the number of processor threads you have. That’s an 8x slowdown on my laptop, and a 12x slowdown on my work machine.

The slowdown is only on this one phase, but this phase can involve the calculating of enough pixels – especially on high resolution images – that it makes a significant difference. A 25% speedup from this fix was measured on one long movie, and on machines with more threads the speedup would be greater. Actual results will vary significantly depending on the images you are calculating and the number of cores on your machine.

Variable speed playback

When doing deep zooms it is often the case that some parts of the movie are more interesting than others and it can be nice to slow down the movie at these points – or maybe you just want to have artistic control over the pacing of your movies. Rendering zoom movies to AVI at a constant speed and then adjusting the playback speed afterwards is inefficient and leads to a loss of quality. Therefore FX 2.20 lets you control the zoom speed when saving to AVI.

To enable this feature check the Custom zoom check box on the Save as AVI dialog in the zoom movie player:


When this is checked the zoom movie player will look for a file with a .fxz.config extension with the same name and in the same directory as your .fxz file. You just need to create this text file and add appropriate commands. Here is an example .fxz.config file:

# Blank lines or lines that start with ‘#’ are comments.

# Set the starting zoom level.
setZoomLevel = 2.0

# Pause for half a second
holdTime = 0.5
# Accelerate to 2.0 zooms per second. Hold that speed from 4.0 zooms to
# 5.0 zooms. The acceleration will be a smooth (sinusoidal) acceleration
# curve from the current zoom level to fromZoom, and the speed will
# then be held steady until toZoom is reached.
zoomSpeed = 2.0, fromZoom = 4.0, toZoom = 5.0
# Accelerate to 4.0 zooms per second, holding it from 7.0 to 10.0
# zooms. The acceleration happens between zooms 5.0 and 7.0.
zoomSpeed = 4.0, fromZoom = 7.0, toZoom = 10.0
# Decelerate to 0.0 zooms per second, halting at 12.0 zooms.
zoomSpeed = 0.0, fromZoom = 12.0, toZoom = 12.0

# Pause for half a second.
holdTime = 0.5

# Go backwards.
zoomSpeed = -3.5, fromZoom = 6.0, toZoom = 3.0
# Stop.
zoomSpeed = 0.0, fromZoom = 0.5, toZoom = 0.5

When you click OK the Fractal eXtreme movie player looks for this file and parses it. If there are errors they will be reported. Otherwise it will tell you how long the movie will be and then save it to AVI.

In addition to specifying an initial zoom level and pauses you specify periods where the zoom speed is constant. You specify this by saying what speed you want and what zooms you want this speed held between. In-between these periods (such as from about 6 seconds to 9 seconds in the graph below) the movie player smoothly interpolates between those speeds.


A sample movie using the data above can be found here.

Specifying periods of constant zoom-speed with the start/stop times given in zoom levels was found to work best because it makes it easy to say that you want to go slowly from zooms 88.3 to 97.2 where there is some cool detail, and then from zoom 101 to 150 you want to be going full speed.

It is important to leave gaps between the periods of constant zoom speed since otherwise there can’t be smooth interpolation and the results will not be as pleasing.

Note that the speed can go negative, meaning that zooming in and then out as you please is allowed. Just be sure to stop before changing directions, or else the results will be jarring, and when the speed is negative be sure to make toZoom smaller than fromZoom.

The chart above was created in Excel by pasting the data from the .avi.log file that is now created whenever you save a zoom movie as AVI.

In closing…

We hope that these new features allow the creation of better fractal zoom movies than ever before.

About brucedawson

I'm a programmer, working for Google, focusing on optimization and reliability. Nothing's more fun than making code run 10x as fast. Unless it's eliminating large numbers of bugs. I also unicycle. And play (ice) hockey. And sled hockey. And juggle. And worry about whether this blog should have been called randomutf-8. 2010s in review tells more:
This entry was posted in Fractals. Bookmark the permalink.

13 Responses to Fractal eXtreme New Version–Better Zoom Movies

  1. Hi Brucedawson Iḿ amazed with the incredible speed of your program. Are you planning to include a parser so that anyone can render their own formulas? Iḿ also working in the developement of an IFS but this time focused on parametric search, trying to go further than the Mandelbrot fractal. It would be nice to try some of my formulas in your app.

    Congratulations for your program!!

  2. brucedawson says:

    I have no plans to make a parser. There is a plugin development kit, complete with high-precision math libraries, so anybody who wants to could write a plugin, to allow going beyond the dozen or so built-in fractals.

  3. This program is pretty amazing! I’m rendering a movie now 500+ zooms, its chugging along using 8 cores. I was just wondering when i select anti-aliasing 4×4 in settings then render an image it seems to be using 2×2 antialiasing instead, is that how its supposed to work?

    • brucedawson says:

      If you’ve selected 4×4 anti-aliasing it should use 4×4. Why do you think it is using 2×2 anti-aliasing?

      • actually what I meant was when you goto render-> make poster it only has one anti-alias checkbox, I wasn’t sure if that was 4x,3x, or 2x or if the options->advanced settings determine the anti-aliasing for poster rendering.

        • brucedawson says:

          Ah — I understand. The poster rendering settings are totally different. I believe it does 2×2 antialiasing but I’d have to check the code. I don’t really recommend using poster rendering now because it only uses one CPU. Better to use a virtual screen to create a high-resolution image. Poster rendering made more sense when memory was limited and CPUs had one core. Now, not so much. A poster fits into memory quite nicely, especially with the 64-bit version.

  4. Pingback: Fractal eXtreme, now cheaper | Random ASCII

  5. Patrick Hamlyn says:

    I wrote a program to explore Mandelbrot back in 1987 or so. It ran on my IBM XT and I jigged it up to record what I explored so it could play back as a ‘movie’ which was actually a series of stills and a semi-animated zoom box which would show which area was going to display next.

    It took a few weeks to put together a demo that ran at a computer expo.

    With Fractal Extreme I can create a movie to do the same in about 5 seconds, and it’s smoothly animated at 2560×1600 instead of stills at 512×256 (approximately, I had a video card with a weird resolution that gave 256 colours…)

    One slight issue – if I create a zoom movie with the full 2560×1600 resolution it produces weird artifacts starting at about zoom level 90 to 120. Weird rectangles with reflected data values etc.

    Yes I understand I don’t need to use such high resolution, I’m redoing a lower res movie to zoom 521, at 1920×1020. I also did one to zoom 720 with several hundred pixels on an edge, and even that looked good, but I want more… if you slow it right down it looks much better in high res.

    • brucedawson says:

      That’s odd that you’re seeing artifacts during playback. Are they completely reproducible on multiple playbacks of the same video? If so that would suggest a rendering bug. Or if they show up more randomly then that would suggest a playback bug. Are you using the OpenGL option in the player? Either way it’s quite odd.

      My recommendation for getting the highest quality is to render at a somewhat lower resolution (half to two thirds of the desired output resolution) with anti-aliasing enabled. When you do that and then playback with bilinear filtering it looks pretty stunning. There will be a tiny bit of blurring around the outside, but the center will always be sharp.

  6. Patrick Hamlyn says:

    Yes 100% reproducible with or without OpenGL selected. In fact you can see during loading of the movie that there is going to be a problem, because half way through loading the displayed frames suddenly shrink to about half size in the top left corner.

    During playback, at about 151 zoom, you start getting the odd horizontal line appearing. Then at 241 strange rectangles appear as in this pic:

    I have half a theory that it might be related to doing a bit of panning during the exploration phase. A quarter of a theory in fact.

    There’s another issue: while playing back, a shadowy crosshatching of lighter lines appears, with the pitch expanding then shrinking then expanding. This is presumably due to aliasing between the resolution of the displayed material and the pixel pitch of the screen, and is to be expected. However when you try to run the movie fast, there is a stutter at the same point of the aliasing cycle, every few seconds which makes the playback very choppy. The aliasing is visible with or without OpenGL, but the choppiness is only significant with OpenGL since it is already choppy without. This goes away at lower resolutions.

  7. Patrick Hamlyn says:

    On a different movie I did, also at 2560×1600, I stopped at zoom 101. The lines started at around 72, the rectangles at 90.

  8. Willie Weppler says:

    I am very pleased with this program. It has impressive speed and accuracy, high maximum zoom, and great features. One thing that has given me some trouble that I haven’t been able to find anything about online has to do with the zoom movie feature..

    So I select to render a zoom movie (say it’s 300 zooms), and once it’s calculated, say, 180 zooms, if I resize the window at that point (the window that contains the pixels of every zoom that is being calculated), then every zoom that is calculated after that point is all thrown off. Every zoom after that point kind of retains the integrity of what it should look like, but it’s like the upper left half of the image is unaffected and then the bottom right half is a disorienting “cut-and-paste” of nearby zooms, all displaced and what not. It makes sense that affecting the window would affect the file since it’s using the pixels themselves in the calculations, but nonetheless I don’t know of any way to redeem my corrupted zoom movies without redoing them entirely, which doesn’t sound very fun given how long it can take to make the deeper zoom movies. Thank you very much.

    • brucedawson says:

      You should not be able to resize the fractal window while a zoom movie is being calculated. It is supposed to be disabled by the modal dialog that displays the progress meter. On my machine it is correctly disabled. I’m not sure why you would be able to resize the window on your machine.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.