Slow start

[shinayser]

Hello!! That is a amazing library, I am playing with it for some minutes now.
But I am wondering, why it takes so much time start the animation after we can the "snap" method.
Perhaps a cache could fix it?

Thank you for your great effort!

[MarcinusX]

Wow, cache...
Yes! Doing the encoding just after the Widget is built instead of doing it on method call will solve the issue!

When I get some free time I'll update it!

Thank you! :)

[Vanethos]

The only thing about the cache is that it will generate an image based on the Widget layout when Snappable Widget Started

So if we are using it on an input area or an image that can be changed, when we call snap we will be "snapping" the old state of the widget

[shinayser]

The only thing about the cache is that it will generate an image based on the Widget layout when Snappable Widget Started

So if we are using it on an input area or an image that can be changed, when we call snap we will be "snapping" the old state of the widget

Pehaps a constructo parameter to give the choice for the user would be nice. Some widgets will not change at all, for those, that parameter would work nicely

[MarcinusX]

Yeah, my idea would be to add a parameter useCache which would default to false

[khangahs]

The animation is quite amazing, and the cache is still a problem to newbies like me. Perhaps, a more in-depth guide and a plugin for this work in the future?

[saviourdog]

please update

[chonghorizons]

I did some tests. I ran the encoding in different setups of isolates. (Code is here: https://github.com/chonghorizons/snappable_isolate_tests)

The surprising result is that turning off the compute and not using isolates was the fastest. Compute was always slower, because of the use of isolates.

So, if you do end up caching it, I recommend you spawn one isolate and not run encoding as a map call. Map will parallelize and it appears that the map function leads to memory problems. Just run it sequentially. Or, don't even run it as an isolate and just chain them as futures you run after each one finishes. I'm guessing (no proof) that with a large number of buckets, the isolate has to store all of the images separately from the main program. And then that causes the memory to swell.

PS. Sorry I didn't run this as a fork and do it the right way. So, you'll just need to diff the my_snappable.dart and your snappable.dart to see the differences. It is pretty clear once you do that.

Also, great plugin. Thank you. I learned a lot from reading your code, playing with the image plugin, and using the compute function.