|
|
|
|
|
by baumgarn
1997 days ago
|
|
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. |
|
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?