How much preloading is too much preloading?

Getting Started Newbie Questions
#1

Hi guys, 

I’m building my first app using Corona SDK. It’s a simple app where each time the user shakes their device, a random image fills the screen, coupled with an accompanying sound and message box overlay. 

There will be 20 different full-screen images and 20 brief 1-3 second sounds, plus the 20 message boxes, which are each also image files. 

Estimating my total file size I get:

20 full-screen images saved as 1242x2208 .jpg files = 15MB

20 sound files = 15MB

20 message box overlay images = 500KB

Total file size would be around 30.5MB. 

Would that be too much to preload? I’d like the transitions between images to be snappy. I’m targeting iPhone 6 Plus/6/5 users but would also like to build with mid-high end Android devices in mind. 

Thank you, 

Chad

#2

Pre-loading is a form of optimization.

The rule of thumb for optimization is, “don’t do it till you find you need to do it.”

From your specs list, I don’t see any reason to pre-load at all.  I don’t think you’ll improve your performance noticeably if you do.

Loading any one image file or sound file at a time will be very fast.  If the transitions lag, then I’d consider loading the images and moving them offscreen (x = 100000, y = 100000 should do it), then translate them to a starting position when you need to do the transition.

-Ed

#3

Hi Ed, 

Holy crap! I never even thought about that idea of moving things offscreen and then transitioning them back. That’s a damn good idea. 

About not necessarily pre-loading everything, that’s great to hear. Yeah, using the simulator so far, I’m not seeing noticeable lag between the background slides themselves, but I am seeing what’s like a bulidup of lag over time as I keep using the Shake feature in the simulator. It just seems like the alpha transitions get a little chunky/laggy after a while. 

Out of curiosity, is it wise to destroy/remove assets after in the way I’m using them for this app? If I understand it correctly, each of the images and sound files I’m using are only occupying memory once, no matter how many times they’re called, right? So when I have the 20 images and 20 corresponding sound files, no matter how many times the user shakes their device, the most that could be loaded into memory is all 20 images and sounds, right? Even if the user randomly hits the same number 10 times in a row, that set of images and sounds would only need to be loaded once?

Anyway, thanks a lot for your help. I’m really having a blast in Corona so far. I have lots of plans for my next apps too. 

-Chad

#4

When you call newImageRect(), here is what happens (not necessarily in this order):

  1. Corona, “Is this texture in memory already?”

  No? - “OS, please load that texture for me.”

  Yes? - “OK, move on…”

  1. Corona, “Do I have memory enough to create a display object record and the associated code?”

  No? - “Hey, memory manager, give me more memory.”

  Yes? - “OK, move on…”

  1. Corona, “OK, now lets make a new record and set up some code to manage a new image rectangle…”

  2. Corona, “Now, lets draw the texture, apply alpha settings, masks, shader stuff, …, done.”

  3. OS, “Dum…dee…dumm… OH, its time to render the next frame, slurp… get the stuff out of video memory and display it. Dum…dee…dumm…”

While, this list a bit tongue in cheek, the important thing to take away is:

  1. Rendering a texture uses texture memory.  Once loaded, the texture itself doesn’t need more memory.

  2. Rendering an object, whether it uses a texture or not, uses both system memory and texture memory.  This grows as you make more objects.  You are responsible for destroying objects to free this memory.

#5

Ah, ok, I’m starting to get it. This is kind of scary though. I’m going to be spending a lot of time and thought figuring out when and where to destroy objects in my apps going forward. 

BTW, thank you very much for taking the time to respond. You’ve saved me a ton of time in trying to figure this out on my own. 

#6

Pre-loading is a form of optimization.

The rule of thumb for optimization is, “don’t do it till you find you need to do it.”

From your specs list, I don’t see any reason to pre-load at all.  I don’t think you’ll improve your performance noticeably if you do.

Loading any one image file or sound file at a time will be very fast.  If the transitions lag, then I’d consider loading the images and moving them offscreen (x = 100000, y = 100000 should do it), then translate them to a starting position when you need to do the transition.

-Ed

#7

Hi Ed, 

Holy crap! I never even thought about that idea of moving things offscreen and then transitioning them back. That’s a damn good idea. 

About not necessarily pre-loading everything, that’s great to hear. Yeah, using the simulator so far, I’m not seeing noticeable lag between the background slides themselves, but I am seeing what’s like a bulidup of lag over time as I keep using the Shake feature in the simulator. It just seems like the alpha transitions get a little chunky/laggy after a while. 

Out of curiosity, is it wise to destroy/remove assets after in the way I’m using them for this app? If I understand it correctly, each of the images and sound files I’m using are only occupying memory once, no matter how many times they’re called, right? So when I have the 20 images and 20 corresponding sound files, no matter how many times the user shakes their device, the most that could be loaded into memory is all 20 images and sounds, right? Even if the user randomly hits the same number 10 times in a row, that set of images and sounds would only need to be loaded once?

Anyway, thanks a lot for your help. I’m really having a blast in Corona so far. I have lots of plans for my next apps too. 

-Chad

#8

When you call newImageRect(), here is what happens (not necessarily in this order):

  1. Corona, “Is this texture in memory already?”

  No? - “OS, please load that texture for me.”

  Yes? - “OK, move on…”

  1. Corona, “Do I have memory enough to create a display object record and the associated code?”

  No? - “Hey, memory manager, give me more memory.”

  Yes? - “OK, move on…”

  1. Corona, “OK, now lets make a new record and set up some code to manage a new image rectangle…”

  2. Corona, “Now, lets draw the texture, apply alpha settings, masks, shader stuff, …, done.”

  3. OS, “Dum…dee…dumm… OH, its time to render the next frame, slurp… get the stuff out of video memory and display it. Dum…dee…dumm…”

While, this list a bit tongue in cheek, the important thing to take away is:

  1. Rendering a texture uses texture memory.  Once loaded, the texture itself doesn’t need more memory.

  2. Rendering an object, whether it uses a texture or not, uses both system memory and texture memory.  This grows as you make more objects.  You are responsible for destroying objects to free this memory.

#9

Ah, ok, I’m starting to get it. This is kind of scary though. I’m going to be spending a lot of time and thought figuring out when and where to destroy objects in my apps going forward. 

BTW, thank you very much for taking the time to respond. You’ve saved me a ton of time in trying to figure this out on my own.