Low framerate on device

Getting Started Newbie Questions
#1

Hi. I am working on an app and am getting 60 fps in the simulator but the framerate on the two devices I have tested on drops to 5 fps. I have tested on an HTC Sensation and a Toshiba Thrive tablet.

The app has a series of images that the user can swipe left and right on the screen to scroll through (like a video). The user can also tap on the screen and the images will play through like a video would play. However, when the image changes, the fps drops to 5. Is there something in my code that I am overlooking or is there a better way to make this app?

if (picNum \<= #imgTest) and (picNum \>= 0 ) then if (math.round((event.x - event.xStart)/pixelsPerImage)) \>= 0 and (picNum \< #imgTest) then picNum = (math.round((event.x - event.xStart)/pixelsPerImage) + dontreset) display.remove( testPic ) testPic = display.newImage("images/vid1/" .. imgTest[picNum] .. ".jpg") testPic.x = display.contentCenterX testPic.y = display.contentCenterY group:insert(testPic) end end
#2

Hi @blondiemc9,

At a glance, this appears to be an issue with trying to load many large images quickly in succession, and/or pushing the limits of those devices’ texture memory. Are you building this like a “flip book” of many large images, and then “playing” the flip book in a quick succession, loading each new image in sequence?

Best regards,

Brent

#3

Hi @Brent,

The “flip book” is exactly what I am trying to do. Is there a better way to implement this? Is there something I have not optimized properly in that block of code?

#4

Ideally, all of the images should be pre-loaded, then shown at the proper time. However, this may exceed your texture memory limit. How large are these images in pixel dimensions?

Brent

#5

The images are 1425 by 900 pixels and average between 35-40 kb in size.

#6

Those images are quite large from a texture memory standpoint. From OpenGL’s power-of-2 standpoint, 1425 rounds UP to 2048, and 900 rounds up to 1024. Then, the typical 4 bytes per pixel would yield:

2048 x 1024 x 4 = 8388608 = 8 MB of texture memory per image.

So, if you have 10 of these, you’re occupying 80 MB of texture memory. This is likely why you’re getting slow performance on those devices.

Brent

#7

Would that still be the case when I am removing the image before displaying another? I have been using this http://developer.coronalabs.com/code/output-fps-and-texture-memory-usage-your-app to monitor texture memory and fps and it displays the texture memory as only a few MB consistently. The only time the framerate drops is when the image is changing. Is there another way to perform this “flip book” idea?

I have looked into making it a video but it seems that the videos in corona are somewhat limited and would not be able to do what I need them to do. Is this possible to do using a video instead of a “flip book”?

Thanks,

Eric

#8

Hi Eric,

Since you’re not pre-loading all images, it’s logical that the texture memory stays roughly the same (since you’re deleting one image when you load a new one). But, this will cause the slow performance on some devices, because you’re loading in a new large image (8 MB of texture memory) into OpenGL’s memory each time the user “flips” to the next image.

I think the best solution, which takes a bit more effort initially from a code standpoint, is to pre-load about 3-4 of these images in advance, then when the user goes to the next one, you load another one in the background (after the new one, which was already pre-loaded, becomes visible). At the same time, remove the previous one to clear up some texture memory.

Brent

#9

Hi @blondiemc9,

At a glance, this appears to be an issue with trying to load many large images quickly in succession, and/or pushing the limits of those devices’ texture memory. Are you building this like a “flip book” of many large images, and then “playing” the flip book in a quick succession, loading each new image in sequence?

Best regards,

Brent

#10

Hi @Brent,

The “flip book” is exactly what I am trying to do. Is there a better way to implement this? Is there something I have not optimized properly in that block of code?

#11

Ideally, all of the images should be pre-loaded, then shown at the proper time. However, this may exceed your texture memory limit. How large are these images in pixel dimensions?

Brent

#12

The images are 1425 by 900 pixels and average between 35-40 kb in size.

#13

Those images are quite large from a texture memory standpoint. From OpenGL’s power-of-2 standpoint, 1425 rounds UP to 2048, and 900 rounds up to 1024. Then, the typical 4 bytes per pixel would yield:

2048 x 1024 x 4 = 8388608 = 8 MB of texture memory per image.

So, if you have 10 of these, you’re occupying 80 MB of texture memory. This is likely why you’re getting slow performance on those devices.

Brent

#14

Would that still be the case when I am removing the image before displaying another? I have been using this http://developer.coronalabs.com/code/output-fps-and-texture-memory-usage-your-app to monitor texture memory and fps and it displays the texture memory as only a few MB consistently. The only time the framerate drops is when the image is changing. Is there another way to perform this “flip book” idea?

I have looked into making it a video but it seems that the videos in corona are somewhat limited and would not be able to do what I need them to do. Is this possible to do using a video instead of a “flip book”?

Thanks,

Eric

#15

Hi Eric,

Since you’re not pre-loading all images, it’s logical that the texture memory stays roughly the same (since you’re deleting one image when you load a new one). But, this will cause the slow performance on some devices, because you’re loading in a new large image (8 MB of texture memory) into OpenGL’s memory each time the user “flips” to the next image.

I think the best solution, which takes a bit more effort initially from a code standpoint, is to pre-load about 3-4 of these images in advance, then when the user goes to the next one, you load another one in the background (after the new one, which was already pre-loaded, becomes visible). At the same time, remove the previous one to clear up some texture memory.

Brent