Why such high memory usage for simple sequential animation sequence?

edited November 2013 in Questions about Code

Recently I've been trying to discover why my relatively large Processing sketch (2.0.3) in JavaScript mode is taking up an entire gig of RAM when run.

I've boiled down several hundred lines of code to this simple example below.

Is this normal for a simple sequential animation sequence to be taking up ~250MB of memory when run? Am I doing something wrong? The assets are only 2.3MB in total file size and the amount of memory usage seems like overkill. Every time I add one of these styles of animations the memory usage just keeps skyrocketing. Since JavaScript has such untouchable memory management, this is proving really problematic.

Any insight would be greatly appreciated! :-)

===============

int currentFrame = 0; // holds what frame of the animation we are on
int COVER_ANIMATION_FRAMES = 32; // number of frames in our animation
PImage[] coverAnimation = new PImage[COVER_ANIMATION_FRAMES]; // our animation

void setup()
{
  // General setup
  size(1024, 768);
  imageMode(CENTER);

  // Set our framerate for the cover page
  frameRate(4);

  // load all of our images into the image array
  for (int i = 0; i < COVER_ANIMATION_FRAMES; i++) {
    String imageName = "Animation/Page0/cover_page_animation" + i + ".png";
    coverAnimation[i] = loadImage(imageName);
  }
}

void draw()
{
  background(155);

  // display our current frame of animation
  image(coverAnimation[currentFrame], width/2, height/2, coverAnimation[0].width, coverAnimation[0].height);
  // move to the next animation image
  currentFrame += 1;
  // when you get to the end of the animation, loop the last frames of the animation
  if (currentFrame >= coverAnimation.length) {
    currentFrame = coverAnimation.length-6;
  }
}
Tagged:

Answers

  • When an image is saved to disc it is compressed but when loaded it will be stored in 32 bit ARGB i.e. every pixel requires 4 bytes of RAM. So an image 1024 * 768 would require 3 Mb and 32 of them would require 96Mb (minimum)

  • Thanks for that explanation, quark!

    Besides obviously cutting down the size(x, y), is there anything you can do to bump this memory usage down? I'm not doing any manipulation of the images at all besides just displaying them but I did want them at that size (the sketch is a book application so the size matters for visual impact).

  • Dunno what's wrong either. Perhaps those constant resizing? #-o
    Anyways, experiment this lighter version just to see whether it lowers RAM usage: O:-)

    final static int FRAMES = 32;
    final PImage[] animation = new PImage[FRAMES];
    
    final static String PATH = "Animation/Page0/";
    final static String NAME = "cover_page_animation", EXT = ".png";
    
    void setup() {
      size(1024, 768);
      imageMode(CENTER);
      frameRate(4);
    
      for ( int i = 0; i != FRAMES;
        animation[i] = loadImage(PATH + NAME + i++ + EXT) );
    }
    
    void draw() {
      background(0250);
      image(animation[frameCount%FRAMES], width>>1, height>>1);
    }
    
  • edited November 2013

    ... but I did want them at that size...

    What size? From 1st PImage? X_X
    If so, why not resizing them all within setup()? (:|

    //forum.processing.org/two/discussion/1078/
    // why-such-high-memory-usage-for-simple-sequential-animation-sequence
    
    final static int FRAMES = 32;
    final PImage[] animation = new PImage[FRAMES];
    
    final static String PATH = "Animation/Page0/";
    final static String NAME = "cover_page_animation", EXT = ".png";
    
    void setup() {
      size(1024, 768);
      imageMode(CENTER);
      frameRate(4);
    
      animation[0] = loadImage(PATH + NAME + 0 + EXT);
      final int w = animation[0].width, h = animation[0].height;
    
      for ( int i = 1; i != FRAMES;
        (animation[i] = loadImage(PATH + NAME + i++ + EXT)).resize(w, h) );
    }
    
    void draw() {
      background(0250);
      image(animation[frameCount%FRAMES], width>>1, height>>1);
    }
    
  • I can actually nix that resizing portion because the images are already 1024 x 768.

    Unfortunately still ~250MB of memory usage... although I am quite impressed by your simplification of the code, GoToLoop :-bd

    I'm just beginning to think Processing isn't the correct medium for what I'm trying to do... which makes me very sad because I do enjoy using it quite a bit. Maybe just not for this project!

  • Answer ✓

    Depends on what you are trying to do but most platforms will un-compress image files (jpg, gif, png ...) to the same colour resolution as the display adapter (graphics card).

    SInce most computers use 32 bit color displays then you can't avoid the 4 bytes per pixel memory usage.

    The reason for matching the colour format is pure speed since there is no further conversion needed to display the images (especially important in animation)

  • Hey quark,

    Gotcha. The end goal was to run the Processing sketch in JavaScript through PhoneGap to run on both iOS and Android devices.

    Unfortunately Apple has really, really strict memory management guidelines so just running on an iPad 2 my sketch gets killed because of "memory pressure" after ~275MB memory usage... So... Yeah... Almost can't even handle this one animation let alone an entire book! :-(

    Probably no other thoughts that could save this? If not I will mark the above post as the answer.

  • With Android and IOS devices then memory is always at a premium. You might try to record the animation as a movie, you might think this would use more memory but it would depend on the difference between frames and the compression codec used (or in your case the difference between images)

    When you say 'entire book' what type of application are you trying to create?

  • Ah interesting thought about the movie... I didn't think Processing could handle videos in JavaScript mode?

    Working on an interactive children's book application.

    I think probably the best route at this point is to just do this all through JavaScript/HTML/CSS and export the animations as animated GIFs. I'm not doing anything too crazy with the interactives so I think what the web languages offer will suffice.

    Which is a shame because I really do prefer how easy it is to build layouts in Processing... :-(

Sign In or Register to comment.