Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory on using animation.KeyframeAnimation #94

Open
ZhenguoYang opened this issue Jun 17, 2013 · 5 comments
Open

Memory on using animation.KeyframeAnimation #94

ZhenguoYang opened this issue Jun 17, 2013 · 5 comments

Comments

@ZhenguoYang
Copy link

We did the following tests for the same animation behaviour:

  1. Use KeyframeAnimation to read one combined picture (contains 12 small pictures) and run the animation. (Chrome Memory: 28M);
  2. Use KeyframeAnimation to add 12 frames (12 small pictures) seperatelly and run the animation. (Chrome Memory: 19M);
  3. Use setInterval (change background pic each 200ms) to replace KeyframeAnimation (12 small pictures). (Chrome Memory:18M);
  4. Use setInterval (change background pic each 200ms) to replace KeyframeAnimation (one combined pictures). (Chrome Memory: 12M)

Any suggestion?

@tonistiigi
Copy link
Member

(All this info is just guesses, didn't test actual data)

The difference between 1 and 2 is most likely because Lime slices up the image and puts every part to a separate canvas. This is needed for the repeating to work separately for every slice. In no-dom branch this has been optimized and new canvas is created only if the frame goes over the edge, but I think this was only for Canvas renderer. Other thing to try is setting lime.fill.Frame.prototype.USE_CSS_CANVAS = false. In theory it should limit the memory usage(depends if Chrome optimizes or not) but you need to check if it affects the framerate or not.

I have no idea about the difference between 2 and 3. Possibly just Javascript objects or something gets put to a separate layer.

3 and 4 is some Chrome optimization. For example the textures you send to the graphics card can only be on certain sizes(power of 2) so every image is actually made larger. Or some overhead on hidden objects that keep references to the images.

@qyapps
Copy link

qyapps commented Oct 31, 2013

You mentioned there is some optimization in no-dom branch in new canvas creation. Do you like to merge this optimization into the main branch?

@tonistiigi
Copy link
Member

Sorry. The no-dom branch is not feature complete. There are some issues with the label fonts and I think some edge cases with frame fills are not handled. I could rebase it though so it also gets the latest bugfixes from the master if that helps.

@qyapps
Copy link

qyapps commented Oct 31, 2013

That will help. Thank you for doing this.
Also if the no-dom branch is not feature complete, is it possible to just add the optimization part into the main branch? I see there are some changes related to the optimization in frame.js and image.js. I wonder changes in these two files can be added alone into the main branch.

@tonistiigi
Copy link
Member

@qyapps no-dom branch is rebased now.

I think there are too many dependencies on other changes to safely move these features. But if you do it, test it and make a PR then I'll surely merge them to master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants