HTML5 Mandelbrot set & Julia sets

 

Falcosoft on Facebook

 

Falcosoft on Google+

Falcosoft animation

Max.Iteration:

Bailout value:

Multithreading:

Coloring Procedural

Red multiplier:    Green multiplier: Blue multiplier:    /100

VGA B&W Nice

!

You need a HTML5 compliant browser to use this page. (Use Firefox, Chrome, IE9+ etc.)

!

 

Informations:

Left Mb:zoom in area, Ctrl+Left Mb:zoom out area, Right Mb:move, Wheel:fine zoom in/out.

Left Mb click:switch between the Mandelbrot set and the corresponding Julia sets.

You can mirror the image by using area zoom from reverse directions.

This is only a HTML5 canvas demonstration. For a full featured Mandelbrot / Julia set generator download MandelX.
Contrary to native programs javascripts can't detect hardware and can't determine the number of your CPU cores. So this application can only detect if your browser supports web workers and set the multithreading option accordingly. But if you have only one CPU core the enabled multithreading will be slower for you because of threads overhead. In this case you should disable it, but the performance penalty on IE10, Chrome or Firefox is negligible. Opera currently implements web workers in one thread, so in case of Opera multithreading should always be disabled regardless of its web workers support. Some Chrome and video driver combinations cause dramatic slowdown if GPU accelerated 2d canvas is enabled. Try to disable this option on the about:flags configuration page.

 

Benchmarks:

Here are the benchmark results of current (January 2013) windows based PC browsers representing the number crunching power of their javascript engine:

 

Browser javascript benchmark

 

I noticed on my legacy system (Athlon XP 2200+) that Mandel4 preset is surprisingly slow. Knowing both architecture (K7, K10) fairly well I thought this magnitude of speed difference in single threaded mode is not reasonable. Considering the relatively small amount of data big speed differences can be attributed to either smaller and slower caches (and certainly not the absence of integrated memory controller) or the lack of SSE2 support in the K7 core. So I decided to make an experiment with the help of my program Phenom II Tweaker. I had disabled the SSE2 feature flag on my Phenom II and repeated the tests. Bingo. The cause of the dramatic slowdown seems to be the missing SSE2 support. Here are the results:

 

Browser javascript benchmark w/o SSE2

 

I have included Firefox 8.01 result for comparison (last version of Firefox with acceptable legacy code performance). Multi-threaded numbers are missing since they are irrelevant.
Every browser is slower without SSE2 but the magnitude is different. IE9 virtually shows the same results as before, but e.g. Firefox 17.0 is dramatically slower. Well optimized x86/x87 code should not be so much slower than SSE2 code. It seems that the legacy code path is not too important for modern browsers. I think this approach is understandable but I also think the x86/x87 code path can be made more efficient than this without too much effort. Overall the moral of the story is that if you have an older system (Pentium 3, Athlon XP) and you visit javascript heavy pages you should choose your browser carefully.