2 things I really hate about Corona right now...

Solar2D General Questions/Discussion
#1

  1. The slowness in loading images. We implemented 9-slice in our entire game, and have now reverted back almost everything to regular images. A screen with for instance 50 buttons would be 450 image loads just regular state + 450 image loads for pressed state. It is so painfully slow on Corona. Why? Modern graphic engines should not have any issues with this. And yeah, we’re caching the images on startup.

  2. The need to sprinkle the code with short timers to make the activityIndicators show. Probably 200 places now we do:

native.setActivityIndicator(true)

timer.new(50, function()

   … whatever we wanted to do that required the activityindicator to start first

end)

It would be awesome to be able to use 9slice and not sprinkle the code with timers to make it behave. Is that too much to ask for?

#2

Hi Haakon,

On point #1, can you explain further why 450 images need to be loaded? What was the issue with 9-slice buttons and why did you revert back to regular images?

On point #2, are you hiding (turning off) the activity indicator inside the anonymous function? Can you show a more complete example of how you’re using this and what is contained inside the anonymous function?

Thanks,

Brent

#3

@haakon.

  1. have you already combined all your images in spritesheets? (so you decreases the number of i/o)

  2. the delay is not a Corona problem. Coding natively you would face the same problem. You need to force a small delay to allow the screen to refresh itself.

#4

I’m surprised at your troubles regarding point 1 - I would definitely say that you need to use spritesheetsif you don’t already. I load a 4096 x 4096 image with ALL of my graphics on startup, takes about 3 seconds on my iPhone 4. I would venture that loading images has little to do with the speed of Corona, to be honest. Corona just starts a native process that copies raw data into memory - speed limited by the device, not the framework.

p.s. It’s none of my business, naturally, but why would you need 50 different types of 9-slice buttons, all loaded in memory at the same time? Can’t think of many interfaces that would need an approach like this…

#5

Hi,

no, we’re not using 50 different buttons. It is the same button used 50 times in a list. And yes, we are of course using sprite sheets and preloading images - all the tricks in the book, but that does not change how Corona behaves when it comes to creating instances of a button on the stage (using the 9-slice technique). It just takes (a lot of) time.

#6

Okay, thanks for clarifying. Actually, I don’t feel like it’s a Corona graphics engine issue per se. My level creations is pretty fast - near instantaneous, and that’s with 320 images tiles plus about a hundred objects for the level decor, plus about 30 enemies with each consisting of nested display groups plus serious collision code running each frame.

I don’t really optimise for GL calls, and still it’s fast. I’d need to see or even test code to be sure, but Corona should handle the graphics you throw at it fast enough. Is there a lot of other code being executed for each button creation - like a adding touch listeners and transitions? Try gutting the code to only keep the ‘displaying graphics’ part, and see if the problem really lies on the side of the graphics engine or not, would be my advice.

#7

I have found that the engine is a bit slow when creating over 500 objects specially when using display.newImageRect even if all of them are composed using the exact same image and already preloaded.

For example having a list of about 50 rows that renders a button on each one created with a custom 9-slice class that uses display.newImageRect instead of sprites could take 1 to 3+ seconds to render even on an iPhone 5S. I understand that sprites are faster because all the images are already preloaded, but if Corona caches images with the same name loaded with display.newImageRect it shouldn’t take so long.

Most projects don’t need to render that many images on screen in one shot unless using lists, so I believe widget.newScrollView and widget.newTableView should not render all rows at the same time but rather what’s visible on screen first and the rest afterwards.

#8

Hi @abiasi,

Just to clarify, table views only render what’s visible and then render the rest later (as the rows come on screen).

Brent

#9

Alright thanks for clarifying, I’m using scroll views at the moment.

#10

Corona could, but has not, added two features to scrollView that would make your life easier. One (maxVelocity) was discussed in April without a resolution:

http://forums.coronalabs.com/topic/37217-list-of-open-widget-20-bugs-promised-features/page-11

And the other (really restoring an event that was removed without notice and would help in on-demand rendering) was discussed in January without a resolution:
http://forums.coronalabs.com/topic/43778-restoring-deleted-scrollview-feature-endedscroll-event/

#11

Hi Haakon,

On point #1, can you explain further why 450 images need to be loaded? What was the issue with 9-slice buttons and why did you revert back to regular images?

On point #2, are you hiding (turning off) the activity indicator inside the anonymous function? Can you show a more complete example of how you’re using this and what is contained inside the anonymous function?

Thanks,

Brent

#12

@haakon.

  1. have you already combined all your images in spritesheets? (so you decreases the number of i/o)

  2. the delay is not a Corona problem. Coding natively you would face the same problem. You need to force a small delay to allow the screen to refresh itself.

#13

I’m surprised at your troubles regarding point 1 - I would definitely say that you need to use spritesheetsif you don’t already. I load a 4096 x 4096 image with ALL of my graphics on startup, takes about 3 seconds on my iPhone 4. I would venture that loading images has little to do with the speed of Corona, to be honest. Corona just starts a native process that copies raw data into memory - speed limited by the device, not the framework.

p.s. It’s none of my business, naturally, but why would you need 50 different types of 9-slice buttons, all loaded in memory at the same time? Can’t think of many interfaces that would need an approach like this…

#14

Hi,

no, we’re not using 50 different buttons. It is the same button used 50 times in a list. And yes, we are of course using sprite sheets and preloading images - all the tricks in the book, but that does not change how Corona behaves when it comes to creating instances of a button on the stage (using the 9-slice technique). It just takes (a lot of) time.

#15

Okay, thanks for clarifying. Actually, I don’t feel like it’s a Corona graphics engine issue per se. My level creations is pretty fast - near instantaneous, and that’s with 320 images tiles plus about a hundred objects for the level decor, plus about 30 enemies with each consisting of nested display groups plus serious collision code running each frame.

I don’t really optimise for GL calls, and still it’s fast. I’d need to see or even test code to be sure, but Corona should handle the graphics you throw at it fast enough. Is there a lot of other code being executed for each button creation - like a adding touch listeners and transitions? Try gutting the code to only keep the ‘displaying graphics’ part, and see if the problem really lies on the side of the graphics engine or not, would be my advice.

#16

I have found that the engine is a bit slow when creating over 500 objects specially when using display.newImageRect even if all of them are composed using the exact same image and already preloaded.

For example having a list of about 50 rows that renders a button on each one created with a custom 9-slice class that uses display.newImageRect instead of sprites could take 1 to 3+ seconds to render even on an iPhone 5S. I understand that sprites are faster because all the images are already preloaded, but if Corona caches images with the same name loaded with display.newImageRect it shouldn’t take so long.

Most projects don’t need to render that many images on screen in one shot unless using lists, so I believe widget.newScrollView and widget.newTableView should not render all rows at the same time but rather what’s visible on screen first and the rest afterwards.

#17

Hi @abiasi,

Just to clarify, table views only render what’s visible and then render the rest later (as the rows come on screen).

Brent

#18

Alright thanks for clarifying, I’m using scroll views at the moment.

#19

Corona could, but has not, added two features to scrollView that would make your life easier. One (maxVelocity) was discussed in April without a resolution:

http://forums.coronalabs.com/topic/37217-list-of-open-widget-20-bugs-promised-features/page-11

And the other (really restoring an event that was removed without notice and would help in on-demand rendering) was discussed in January without a resolution:
http://forums.coronalabs.com/topic/43778-restoring-deleted-scrollview-feature-endedscroll-event/