Original author here! The original implementations of Zoomquilt 1+2 were done in flash. I created the HTML5 port in 2013. Zoomquilt 2 consists of 88 single images, each 1024x768px. Basically each image takes place at 50% the size in the center of the previous. For each frame, there are at most 4 images rendered at once on the canvas. The first Zoomquilt has smaller images of 800x600, hence the better performance. Arkadia.xyz has source images of 1200x900px.

The performance in Chrome is noticeably better than Firefox. The smaller the window size, the smoother the playback. Since it is only four images at once, whenever one image leaves the scene and a new one appears, there might be a small lag when the image is loaded into memory. I don't have a deeper understanding on how this could be optimized further for the browser.

For the Android OpenGL implementation I was able to take care of loading the images asynchronously before they enter the scene and freeing up the memory again after they leave the scene.

Happy to take suggestions on how this might be optimized further, as it would be interesting to work with even higher resolutions for future projects, but this quickly leads to much higher performance load and choppy playback on weaker machines.

That should be about 360MB of uncompressed data (1024x768x88x4 bytes) which should fit into the memory of most IGPs, which generally reserve 1 or 2 GB. Compositing 4 images at once should be something that even a very old GPU should have no problems with, even at 4K resolution. Windows Desktop Composition probably does a lot more work.

Still this indeed gets my laptop's fans spinning in both Chrome and Firefox. I wonder why that is... I don't think you can do a lot wrong code wise here. Maybe the composition takes a software path, but why?

Hi! I was just looking into it, see my other comment below. FF is terrible at resizing on `drawImage`, you can render at half resolution [1] to improve performance, and the smoothness makes up for the lost definition. Other tricks like rendering offscreen don't really do much, I guess using CSS transforms or WebGL would be the only other options but a ton more effort.

Thanks for these, they are incredible!

[1] when devicePixelRatio > 1, in FF only. Gets me from 24ms to 7ms/frame here

Thanks for pointing this out! Great suggestion, I will try it out.

Thanks for making this and for porting it to android! I changed phones about a month back and stumbled upon your wallpaper app by chance. It has made my homescreen such a delight these days as I never know what I'll see. Thanks again!

Great to hear! Glad you enjoy.

Upon a few moments of reflection, it's obvious to me I should just buy the 3rd wall paper both to see what I'm missing and to support this fine work. Thanks again!

Thanks mate! You can see the full thing for free here http://arkadia.xyz, It's just the Live Wallpaper version to purchase and support the artists;)

Any resources you can provide, so I can make my own site and all the art?

The website says "ZOOMQUILT 2 An infinitely zooming painting created in 2007" (Version 1 is from 2004) and on both pages it says "A project by Nikolaus Baumgarten". So it doesn't seem to be the case that we compare two eras of web-dev here.

Indeed, the original was in Flash, it was only ported to canvas much later.

I can't even notice the load on the system - Chrome's task manager tells me it's using 10% CPU, and I'm running on a 4k monitor.

EDIT: just tested with Firefox on MacOS and it's incredibly choppy and CPU-hungry. the `drawImage` call always goes over budget for RAF, there are a ton of open issues about it: https://bugzilla.mozilla.org/show_bug.cgi?id=1602299

Drawing at half scale gets it back to 60ms with time to spare:

    window_w = w * dpr / 2;
    window_h = h * dpr / 2;

Seems fine on Safari for me.

60fps*

It’s smooth as silk on my iPhone 7 (4 year old, mobile hardware). I wonder if maybe it’s using some webgl feature that your machine doesn’t accelerate natively?

For me, resolution is the problem. If I reduce window size from ~4K to a fraction of that, the animation changes from being painfully choppy to smooth. I'm running a fairly powerful desktop machine with a gaming GPU.

It uses 17-25% CPU with Chrome, 4k fullscreen, 60fps and I use a Dell XPS laptop.

that's tons since for windows 100% is all virtual cores utilized. If the machine is 4 cores/8 threads - that's one full core.

Big deal. That's literally why you've got 3 more cores.

With that logic, you can never run more than 4 applications at once. The point is that for what it does, it shouldn't even be close to utilizing a full CPU core on a modern machine.

Well, for that matter, for what it does, it shouldn't even exist.

Huge deal not everyone is running 4 cores.

Core i5 first generation came out in 2009 with 4 cores: https://en.wikipedia.org/wiki/List_of_Intel_Core_i5_processo...

Even with the 3 extra cores for most laptops it means thermal (or power) throttle and likely high memory and cache pressure.

Anecdotally it uses about 1.5% CPU on my laptop with the current Firefox stable on Windows 10 20H2. Admittedly this is a machine with an 8 Core / 16 Thread CPU, but that still feels reasonable. Firefox overall is reporting around 3.5% usage with a YouTube video playing in 1080p fullscreen, Discord and three other open (and loaded) tabs.

Pretty similar setup and results. Was using 0.5%-1.5% before opening Zoomquilt 2, and using 1.6-2.7% after.

(Ryzen 7 4800H, Windows 10 20H2, Firefox 84.0.1, 1080p screen)

Exactly the same setup even. I was struggling to find the "About Firefox" option earlier, but I checked again (why is it in the help sub-menu?) and I also have 84.0.1.

The power of confirmation bias. A factually incorrect comment on a tangential topic is still the number 1 comment after 3 hours just because it appeals to those who bemoan modern web development.

I'm not sure what's going on, but I opened it in Chrome on a 5 year old PC and had no fans going, no choppy framerate, no nothing. I probably could have left it open forever and never noticed.