iPad 3, iPad 2, iPhone 5, and iPhone 4
Performance issues are use-case specific. We do know cases where things do speed up thanks to automatic batching, but as ingemar astutely pointed out, we are exercising the GPU differently, so there are use cases that get handled differently.
@rakoonic, can you send over the project you were using with the rotating sprites? That sounds like the use case that’s generating the hotspot.
@XWL/@spideri, are you seeing the slowdown on all devices? Similarly, if you have a project, it will help us understand in what situations you are seeing a slow-down.
Yeah its across all devices. The situation that its most noticeable in is as follows, (all dimensions are referring to iPad 3, for all other devices it is half):
Theres one full sized image loaded as the background (4096 x 4096).
There is four (4096 x 4096) and one (2048 x 4096) image sheets loaded, as well as a few smaller ones.
There is 3-5 elements on the screen loaded from the half size sheet.
There is up to 200 of the same two elements repeated on the screen (100 of each), loaded from a (512 x 1024) image sheet: each one is always moving, and is scaling x and y about 30% of the time. They are also mostly transparent (not alpha’d out).
And to top it off, ALL objects on the screen, including the background, are changing rotation every frame.
Sorry but thats about all I can give you right now. To make an isolated test project would take me several days that I don’t have at the moment.
So essentially, lots of images loaded from large image sheets, and lots of movement, scaling, and rotation. Texture memory is maxed out as you would imagine.
edit: Oh and I’m using the accelerometer at an interval of 30
Hi Walter, thanks for looking into this so quickly. Some device captures from the S4…
Old version: https://www.dropbox.com/s/1x7ygova9uhmoyr/FH_Benchmark%20Picture%202.png
Graphics 2.0: https://www.dropbox.com/s/7wc7ipxebsztn41/FH_2.0%20Picture%204.png
Which is great at it shows a much more consistent frame rate with a lot less thrashing! 
Our GameStick problem persists though. Anything you can do to help would be awesome. I’ll send you a link to the project via email.
@Walter I don’t have it, but next time I see lKinx on IRC I’ll tell him to pass it over.
I have a question though:
Why did you change the load point for images from G1 to G2 - IE what were you hoping to achieve?
It seems to me in just about every case loading upon actual request (IE when you call newImage() ) has got to be the way to go - not only does it make more sense generally, but people have taken advantage of this feature to ensure all level loading etc happens at a specific time - IE when you chuck up the ‘level loading’ messages.
This is a non-trivial change which IMO makes very little sense, and as you’ve seen, is causing a fair amount of problems.
I’m curious why such a change was not announced when it got rolled into the betas, so it was more widely known and could have been discussed at the time.
I think the current implementation is sub-standard, so I’m trying to understand how we ended up here.
@rakoonic, as mentioned above, we’re working on a new API that will allow you to control this, so you get to control the pre-load.
As requested. On my iPad 3 I see no noticeable performance difference between G1 and G2 (with lots of particles).
G1: https://www.dropbox.com/s/h6l6i9ncrs340ft/Photo%2021-11-2013%2010%2006%2047.png
G2: https://www.dropbox.com/s/69a9zyq5910mmzr/Photo%2021-11-2013%2010%2015%2057.png
They both start thrashing the same once a certain number of particles is reached. Great that G2 uses less video memory though.
@Walter Can we get that 5000 fish sample please?
Apologies, Walter, I missed that bit.
Thanks for all of the feedback. In the upcoming daily build, we have changed the default behavior to load textures at the time of the newImage call.
To opt-out of this and lazy load the image, we added a new option: display.setDefault( “preloadTextures”, false )
Super! This sounds like a best fit solution for all. Thank you very much.
This works great! Thank you!
This isn’t be needed anymore as of build 2087:
Release notes for build 2013. through 2013.2087
Core: Adding new option to display defaults to preloadTextures via display.setDefault( “preloadTextures”, true/false ) (default is true to function like graphics 1.0)
That sounds weird. Can you tell us more about what you’re doing in your project that is processor intensive?
During the Beta period, we worked with many developers. The dialogue we had with them allowed us to identify many hot spots and address the performance issues they were seeing. So if you give us more information, we can work together to get to the bottom of this.
I know that there are issues with devices that use the PowerVR SGX535 GPU. The devices include the iPad 1, iPhone 4 and iPod Touch 4th generation. The problem is that the GPU mentioned above is underpowered and Graphics 2.0 pushes the hardware in ways that Graphics 1.0 didn’t.
When I tested on these 3 devices, it looks like the problem lies with the hardware, and not Corona.
In my testing the iPhone 3GS and iPhone 4S have been able to perform as expected though. However my apps are not all that processor intensive. One thing that strikes me is that you mentioned problems on the iPad 2, which I haven’t seen with my projects.
Ok, after noticing that the freezes at the beginning were consistently timed we began to test each part of the code until we discovered what caused it.
Basically, any time you raise an images alpha from 0 it causes a system-wide delay. This includes transitioning it from 0 alpha, or just changing it from 0. The delay is not perceptible until you get into larger images, or images that were loaded from large image sheets.
A 1024 x 1024 image on the iPad 3 had a momentary freeze, while a 1024 x 512 did not have any percievable freeze. The larger the image, the longer it freezes. In our app we are using several full size images and image sheets, so this causes a serious problem.
Also it seems that this only happens the first time an object is set to 0 alpha. Subsequent times it can be set to 0 then changed with no issue.
Steps to reproduce:
Load an image at least 1024 square.
Set alpha of image to 0.
Create a circle, 5-10 px radius.
Set circle xy to top left corner.
Transition circle to bottom right corner over 15 seconds.
Delay 5 seconds, then set alpha of image to 1.
Right when the image changes alpha you will see the circle stop for 0.5 - 3 seconds depending on the size of the image.
EDIT:
I believe that Cublah has the same issue here - http://forums.coronalabs.com/topic/40876-transitions-in-graphics-20/
Thanks for the steps to reproduce - we will look into this.
Wow, thought I was crazy. I downloaded the new engine, and there are performance issues. On windows, when I save a project it takes several seconds to load on the simulator. Device performance took a dive too, so I went back to earlier public release.
I spent quite a bit migrating, so after losing a day or two - I called the ball and went back. In my game, we are doing random generated backgrounds with for loops, and before everything was peachy. But now, it’s like 20 to 40% drop. I went back to previous public release, no issues - I can run on iphone4s and up fine (iphone4, ipod4 are not interesting to me, runs like dog crap on those anyway no matter what I do).
like XWL, I’m using larger images and a config lua using 800x1200 with 1425x900 images and 2850x1800 (the “modernizing” config lua).
All I’m saying it seems that the public release isn’t optimal yet.
-Nick
Not to detract from this thread (I hope Coronalabs gets to the bottom of these G2.0 performance issues), but if you are using images that are natively 1425x900 and 2850x1800 pixels then you wasting a lot of texture memory and bandwidth since textures get up-scaled to the nearest power of two size when loaded into texture memory. Your 1425x900 will get converted to 2048x1024, and the 2850x1800 will get converted to 4096x2048! Those are big, honkin’ textures!
If you downscale your texture images to a power of 2 size in advance you will save a ton of memory/bandwidth at the cost of some minor blurring that you might not even notice. As an added bonus your app download size will be much smaller. I’d scale the 1425x900 down to 1024x1024, or even 1024 x 512. Scale the 2850x1800 down to 2048x2048 or even to 2048x1024. That would be a 4x reduction in texture memory and you might not need to write off the iPhone/iPod 4 after all.
-Stephen
P.S. - I should mention that downscaling the textures files to a power of 2 size is all you need to do. You don’t have to change your config.lua, or mess with any of your existing Corona/lua code, it will all just work.
From what I understand, you want to scale up if you can and not scale down as that takes more cpu power. At least that’s what I’ve been reading. The images I am using are about 30 to 40 kb a piece (they are hills, background terrain so to speak where the whole image isn’t used).
For performance, I’ve written my prototype dead simple with system shapes (squares, circles etc) but because it’s randomly generated on the fly based on what the player is doing that generation algorithm just kicks iphone/ipod 4 in the pants and runs at a paltry 40fps. Since the game is based on dragging your finger around QUICK, lower fps = lower accuracy for finger dragging = jumpy dragging = unplayable game.
Something else to add to that, using config lua settings of 800x1200 vs 480x320 results in MUCH more accurate dragging. The lower res results in skipping jumpy touch. I was forced to go with 800x 1200 for that reason alone, the problem is worse when going to ipad it skips all over the place, unless I use the 800 1200 config lua settings.
I know fun right?
But back on point, the performance was FINE before, but now it’s not. It’s ok though, I’m not using any fancy gfx 2.0 features so I’ll still with the older builds for now until it’s sorted
-NIck
Hi Nick,
Sorry I wasn’t clear, the idea is to pre-scale down the textures in, say, Photoshop, before you use them to build your app, not scale them down in the app.
Your 2850x1800 texture file might be 40kb on disk (I’m guessing it is has a lot of transparency and solid color fills?) but that is the compressed png file stored on disk. It still must be uncompressed into full 32 bit glory to be used by a device’s graphics hardware memory, (plus expanded to that pesky power of two size), so it becomes a 4096x2048x32 bits = 24 MB texture! Also, I think most older devices don’t even support 4096 texture sizes (not sure about iPhone 4).
Sorry if I derailed this thread, but I cleared up a lot of device performance issues in my own projects with this kind of easy optimization so I thought it was worth sharing. If G 2.0 is a step down in performance (hopefully temporarily) perhaps other optimizations can help boost it back up.