Pixelate image takes too long about fraqture HOT 8 CLOSED

I've been doing some research into this, and I agree that it starts off with too small of a sample. This can easily be fixed by changing pixel-multiplier to a higher number. I think 3 or 5 is a good starting point.

This doesn't solve the whole issue, though. If you lein run pixelate the animation takes less than a minute to complete. However, when you lein run cycle, the animation may take longer.

There seems to be a correlation between how long pixelate takes to run and the animation that precedes it. The following examples were run with pixel-multiplier set to 5.

Shifting Grid is clearly the biggest culprit here. I'm not sure what's causing the issue, but certain algorithms cause pixelate to run very slowly. The time between pixel changes seems to increase significantly.

Hopefully this can at least provide a starting point for solving this issue.

from fraqture.

Interesting! It doesn't look like we set the frame rate in pixelate- could you try running (q/frame-rate 30) in the setup function of shifting grid? It looks like those times correlate with the frame rates of those drawings.

from fraqture.

Confirmed. Changing q/frame-rate in shifting grid changes the speed pixelate runs at. By setting the frame rate in pixelate, it seems to run at a consistent speed now.

from fraqture.

I always thought it was because of varying resolutions of the input images, since the pixel size is set to a constant 10 here
https://github.com/smashingboxes/fraqture/blob/master/src/fraqture/pixelate.clj#L10-L11
and then looks like that value becomes a straight pixel coordinate here (modified by mult, but still not scaled by the image resolution)
https://github.com/smashingboxes/fraqture/blob/master/src/fraqture/pixelate.clj#L16-L17

Would it help if the starting pixel-width & height were proportional to the image resolution? pardon my procedural syntax, but something like
int size = max(image.width, image.height) / 40;
if you wanted to start with 40 of them along the longest edge.

from fraqture.

The resolution of the image doesn't seem to have an effect on the time of the animation. For example, the code.png image is 2548x1438 and the flower.jpg has a resolution of 713x500. Both take 36s to run through the whole animation.

I believe it may have to do with the way it divides the number of pixels remaining. It may start off the same every time, but I believe the number of pixels removed through each iteration is proportional to the image size.

from fraqture.

I believe the speed should only be dependent on the resolution of the screen, not the resolution of the image. Those lines that you linked scale based off of screen size, not image size.

from fraqture.

ah yeah I see it now, xs/ys are scaling it 👍

from fraqture.

Thanks for digging into this @TylerRockwell!

from fraqture.