Author Topic: Randomize Overlaid Circles (Read 22507 times)

Tomaaz · « **Reply #45 on:** September 22, 2016, 07:52:41 PM »

Quote from: B+ on September 22, 2016, 07:41:41 PM

Here is Connett Circles, "The Movie"...

Wow! That looks psychodelic.

Tomaaz · « **Reply #46 on:** September 27, 2016, 12:46:00 PM »

I was so impressed by the speed of manipulating image data directly that I decided to rewrite my Mandelbrot animation using this approach. And, again, the result is mind-blowing! It's faster than FreeBASIC.

Code: [Select]

<!DOCTYPE html>
<html>
<head>
	<title>Mandelbrot Set</title>
	<meta charset="utf-8">
	<style type="text/css">
		body {background-color: black}
		div {text-align: center}
	</style>
	<script>
		przelx = 3 / 240;
		przely = 2 / 160;
		powiekszenie = 1;
		przesx = 14.17799995;
		przesy = 79.999904;
		function rysuj() {
			canvas = document.getElementById("rysunek");
			ctx = canvas.getContext("2d");
			ctx.fillStyle = "#000000";
			ctx.fillRect(0,0,240,160);
			var canvasData = ctx.createImageData(canvas.width, canvas.height);
			przelx = 3 / (240 * powiekszenie);
			przely = 2 / (160 * powiekszenie);
			for (x = 0; x < 240; x++) {
				x3 = x - 120;
				for (y = 0; y < 160; y++) {
					var idx = (x + y * 240) * 4;
					y3 = y - 80;
					c = 0;
					a = 0;
					b = 0;
					z = 0;
					x2 = (przelx * (x3 + (przesx * powiekszenie))) - 2;
					y2 = (przely * (y3 + (przesy * powiekszenie))) - 1;
					while (c < 255 && z < 4) {
						a2 = a * a - b * b;
						b2 = 2 * a * b;
						a = a2 + x2;
						b = b2 + y2;
						z = a * a + b * b;
						c = c + 1;
					}
					if (c == 255) {
						c = 0;
						k = 0;
						l = 0;
					}
					else {
						k = (c % 50) * 5;	
						l = 255 - c;
					}
					canvasData.data[idx + 0] = c;
					canvasData.data[idx + 1] = k;
					canvasData.data[idx + 2] = l;
					canvasData.data[idx + 3] = 255;
				}
			}
			var kupa = ctx.putImageData(canvasData, 0, 0);
			if (powiekszenie < 1562550000000) {
				powiekszenie = powiekszenie + powiekszenie * 0.1;
				var t = setTimeout("rysuj()", 0);
			}
		}
	</script>
</head>
<body onload = "rysuj()">
<div>
<canvas id="rysunek" width="240" height="160"></canvas>
<form name="czas">
<input type = "text" id = "pole" style="background-color: black; color: white; border: none">
</form>
</div>
</body>
</html>

This runs at the full speed, some parts are faster than others (due to a different amount of calculations that need to be used to render different part of the fractal). If you want to do it a bit slower and smoother just increase the number in this line: var t = setTimeout("rysuj()", 0). Zero means that the function will be called again instantly. If you specify the number it will be the number of milliseconds the function will be called again after the program returns from the previous call. Again, it runs much faster in Firefox than in Microsoft's browsers.

jj2007 · « **Reply #47 on:** September 27, 2016, 05:36:33 PM »

Quote from: Tomaaz on September 27, 2016, 12:46:00 PM

the result is mind-blowing! It's faster than FreeBASIC.

For a browser, it's indeed very fast. Speed depends a lot on colour depth and the number of iterations, though. Try the attachment...
arrow left/right/up/down moves the image
+ key starts zooming in
- key starts zooming out
mousewheel works, too

ScriptBasic · « **Reply #48 on:** September 27, 2016, 05:53:28 PM »

Quote

the result is mind-blowing!

More motivation to get the Script BASIC JavaScript extension module completed.

Thanks Tomaaz for sharing your JavaScript expertise.

Tomaaz · « **Reply #49 on:** September 27, 2016, 05:59:51 PM »

Quote from: jj2007 on September 27, 2016, 05:36:33 PM

For a browser, it's indeed very fast. Speed depends a lot on colour depth and the number of iterations, though.

Speed depend's a lot on number of iterations and colour depth? Well, it's not exactly like that. In this case both speed and colour depth depend entirely on number of iterations (max. 255 in this example).

On my computer, FreeBASIC version that uses the same size, depth and algorithm is slower than this code run in Firefox. I've written Mandelbrot viewer in all languages I've ever tried and untill now FreeBASIC version was the fastes one. Until now.

EDIT It runs significantly slower in IE, Edge and Chromium.

Peter · « **Reply #50 on:** September 27, 2016, 07:47:36 PM »

Quote from: Tomaaz on September 27, 2016, 12:46:00 PM

I was so impressed by the speed of manipulating image data directly that I decided to rewrite my Mandelbrot animation using this approach. And, again, the result is mind-blowing! It's faster than FreeBASIC.

So I made a version in BaCon, added a timer to your Java Script code, and to my code as well.

Result is that the Java Script version using Firefox runs in 4950 msecs average, and the BaCon version compiled with -O3 optimization runs in 5660 msecs average. Pretty cool that Java Script!

Code: [Select]

INCLUDE canvas.bac
'INCLUDE canvas-gd.bac

OPTION VARTYPE FLOATING

WINDOW("Mandelbrot Set", 240, 160)

przelx = 3 / 240
przely = 2 / 160
magnification = 1
przesx = 14.17799995
przesy = 79.999904

SUB rysuj

    przelx = 3 / (240 * magnification)
    przely = 2 / (160 * magnification)
    FOR x = 0 TO 240
        x3 = x - 120
        FOR y = 0 TO 160
            y3 = y - 80
            c = 0
            a = 0
            b = 0
            z = 0
            x2 = (przelx * (x3 + (przesx * magnification))) - 2
            y2 = (przely * (y3 + (przesy * magnification))) - 1
            WHILE c < 255 AND z < 4
                a2 = a * a - b * b
                b2 = 2 * a * b
                a = a2 + x2
                b = b2 + y2
                z = a * a + b * b
                c = c + 1
            WEND
            IF c = 255 THEN
                c = 0
                k = 0
                l = 0
            ELSE
                k = MOD(c, 50) * 5
                l = 255 - c
            ENDIF
            INK(c, k, l, 255)
            PIXEL(x, y)
        NEXT
    NEXT
    IF magnification < 1562550000000 THEN
        magnification = magnification + magnification * 0.1
    ELSE
        PRINT "Done in ", TIMER, " msecs."
        END
    ENDIF

END SUB

'FRAMES(300)
CALLBACK(1, rysuj)
WAITKEY

Unfortunately, browsers do not render GIF images in a correct speed. The fastest Firefox can do is 0.1 second. If you download the GIF below and present it in a picture viewer, the animation will be a lot faster.

Tomaaz · « **Reply #51 on:** September 27, 2016, 09:33:14 PM »

Quote from: Peter on September 27, 2016, 07:47:36 PM

Result is that the Java Script version using Firefox runs in 4950 msecs average, and the BaCon version compiled with -O3 optimization runs in 5660 msecs average. Pretty cool that Java Script!

Yep. I still can't believe how fast it is.

I'm also really surprised it is Firefox that beats other browsers (I would bet on Chromium/Chrome if someone asked me).

Mike Lobanovsky · « **Reply #52 on:** September 27, 2016, 11:11:08 PM »

Quote from: Tomaaz on September 27, 2016, 12:46:00 PM

And, again, the result is mind-blowing! It's faster than FreeBASIC.
.........
Again, it runs much faster in Firefox than in Microsoft's browsers.

Quote from: Peter on September 27, 2016, 07:47:36 PM

Pretty cool that Java Script!

Cool down, guys. What you're seeing in Firefox is not JavaScript's merit. It is the result of ahead-of-time (AOT) compilation of a subset of JS vocabulary to native assembly done transparently in FF by its dev wizards.

Long live AOT and JIT compilation!

Literature:

1) Why is JS so fast in Firefox?

2) Asm.js.

ScriptBasic · « **Reply #53 on:** September 28, 2016, 02:36:59 AM »

Thanks Mike for the info!

I'm installing Emscripten which is a tool to convert C/C++ code to LLVM bytecode and then to asm.js JavaScript code. Emscripten can also generate HTML for testing embedded JavaScript.

I'll post something if it turns out to be interesting.

Mandlebrot Interactive

Update

Generates a huge amount of JavaScript code for simple hello_world.c.

Tomaaz · « **Reply #54 on:** September 28, 2016, 07:40:11 AM »

Quote from: Mike Lobanovsky on September 27, 2016, 11:11:08 PM

Cool down, guys. What you're seeing in Firefox is not JavaScript's merit. It is the result of ahead-of-time (AOT) compilation of a subset of JS vocabulary to native assembly done transparently in FF by its dev wizards.

So?

It's still pretty impressive. I don't really understand your problem. They implemented support for asm.js in their JavaScript engine. Good for them. And for JavaScript.

Quote from: Mike Lobanovsky on September 27, 2016, 11:11:08 PM

Literature:

1) Why is JS so fast in Firefox?

2) Asm.js.

Well, yes. But in 99% cases I've found Firefox to be slower. Even this animation written with Canvas methods will run faster in Chrome. That's why I'm surprised by the speed of Firefox in this case. Mike, you focus to much on theory.

I don't really care if it is asm.js, native code... whatever. I have a piece of JavaScript code and, in Firefox, it runs faster tha FreeBASIC example and that's what matters to me.

Mike Lobanovsky · « **Reply #55 on:** September 28, 2016, 10:55:49 AM »

Quote from: Tomaaz on September 28, 2016, 07:40:11 AM

I don't really understand your problem.

My problem? I've no problems, Tomaaz. My FBSL's been using JIT compilation for years, if not decades.

That's more of a problem of language implementations that don't and won't use it OOTB so that 3rd parties have no other choice but to galvanize them forcibly each in their own unique way. (cf. R.Russell and his LBB Galvanizer)

Quote

Mike, you focus to much on theory.

No Tomaaz. I'm a man of action. Almost all my ideas get implemented immediately on formulation.

Quote

I don't really care if it is asm.js, native code... whatever.

I think you should, from time to time. For all intents and purposes, JJ's Mandel runs at least as fast if not faster, especially in a compatible much smaller window, than that FF trickery that's been disguised in that JS outfit to fool inexperienced users into thinking bytecode can compete with static or dynamic compilation to machine code. I'm even leaving out the discussion of FF's hardware-accelerated OpenGL canvases (in fact, entire pages) that also contribute much to FF being the leader in browser rendering despite its huge size.

This isn't theory, Tomaaz. That's straight-forward practice based on knowledge and reason.

jj2007 · « **Reply #56 on:** September 28, 2016, 11:21:34 AM »

Quote from: Tomaaz on September 27, 2016, 05:59:51 PM

Quote from: jj2007 on September 27, 2016, 05:36:33 PM
For a browser, it's indeed very fast. Speed depends a lot on colour depth and the number of iterations, though.

Speed depend's a lot on number of iterations and colour depth? Well, it's not exactly like that. In this case both speed and colour depth depend entirely on number of iterations (max. 255 in this example).

Yes, my statement was a bit sloppy. More correctly, my Mandelbrot implementation does one Million iterations in about 11 milliseconds on a Core i5. If you resize the window to match the browser example, you might see the difference. Or better, change the browser example so that it shows a full screen ;-)

Tomaaz · « **Reply #57 on:** September 28, 2016, 06:02:48 PM »

Quote from: Mike Lobanovsky on September 28, 2016, 10:55:49 AM

My problem? I've no problems, Tomaaz.

Well, it seems that you have. Problem either with JavaScript itself or me and Peter being impressed by Firefox running that code. That's how the whole argument started.

Quote from: Mike Lobanovsky on September 28, 2016, 10:55:49 AM

No Tomaaz. I'm a man of action. Almost all my ideas get implemented immediately on formulation.

OK. You're man of action, sometimes focused to much on theory (especially when discussing someone else's impressive achievements).

Quote from: Mike Lobanovsky on September 28, 2016, 10:55:49 AM

I think you should, from time to time. For all intents and purposes, JJ's Mandel runs at least as fast if not faster, especially in a compatible much smaller window, than that FF trickery that's been disguised in that JS outfit to fool inexperienced users into thinking bytecode can compete with static or dynamic compilation to machine code. I'm even leaving out the discussion of FF's hardware-accelerated OpenGL canvases (in fact, entire pages) that also contribute much to FF being the leader in browser rendering despite its huge size.

And you say that you have no problems.

No one is trying to fool anyone. No one is hiding any facts. And what's wrong with using all available options to improve a web browser performance??? Once again - I can't understand your problem.

Quote from: Mike Lobanovsky on September 28, 2016, 10:55:49 AM

This isn't theory, Tomaaz. That's straight-forward practice based on knowledge and reason.

That is a theory and a very strange one.

Quote from: jj2007 on September 28, 2016, 11:21:34 AM

Yes, my statement was a bit sloppy. More correctly, my Mandelbrot implementation does one Million iterations in about 11 milliseconds on a Core i5. If you resize the window to match the browser example, you might see the difference. Or better, change the browser example so that it shows a full screen ;-)

Is your example written in FreeBASIC? Because all I said it was that on my computer, FreeBASIC version that uses the same size and algorithm is slower. Did I say this is the fastest Mandelbrot possible? No, so what's your problem guys? It was just a simple example that wasn't meant to prove anything general. Calm down.

Peter · « **Reply #58 on:** September 28, 2016, 08:52:16 PM »

Quote from: Mike Lobanovsky on September 27, 2016, 11:11:08 PM

Cool down, guys. What you're seeing in Firefox is not JavaScript's merit. It is the result of ahead-of-time (AOT) compilation of a subset of JS vocabulary to native assembly done transparently in FF by its dev wizards.

Long live AOT and JIT compilation!

Thanks for letting know Mike. I wonder if the concept of Ahead Of Time compilation also can work for C. I have tried some other GCC optimization options and this brought down the performance even further (from 5660 msecs average back to 5370 msecs average). Maybe with the right options I can achieve the right performance

Best regards
Peter

EDIT: the following system dependent GCC options brought the performance back to 5120 average, getting closer to Java Script AOT compilation: -O3 -fomit-frame-pointer -march=native -flto -mfpmath=both -funroll-loops -ffast-math

ScriptBasic · « **Reply #59 on:** September 28, 2016, 09:44:51 PM »

Quote

My FBSL's been using JIT compilation for years, if not decades.

I feel every BASIC author, project manager and contributor is proud of their accomplishments. Some share the user experience while others share the source. I think it's healthy to have challenges on the forum as it gives us a chance to see different perspectives.

RetroBASIC

News:

Author Topic: Randomize Overlaid Circles (Read 22507 times)

Tomaaz

Re: Randomize Overlaid Circles

Tomaaz

Re: Randomize Overlaid Circles

jj2007

Re: Randomize Overlaid Circles

ScriptBasic

Re: Randomize Overlaid Circles

Tomaaz

Re: Randomize Overlaid Circles

Peter

Re: Randomize Overlaid Circles

Tomaaz

Re: Randomize Overlaid Circles

Mike Lobanovsky

Re: Randomize Overlaid Circles

ScriptBasic

Re: Randomize Overlaid Circles

Tomaaz

Re: Randomize Overlaid Circles

Mike Lobanovsky

Re: Randomize Overlaid Circles

jj2007

Re: Randomize Overlaid Circles

Tomaaz

Re: Randomize Overlaid Circles

Peter

Re: Randomize Overlaid Circles

ScriptBasic

Re: Randomize Overlaid Circles