If I use storyboard.loadScene(), do I also have to set the flag?
Put it another way, does the storyboard.loadScene() count as loading images with alpha=0 for the new engine??
We have a workaround to address the large image load causing a visible stutter. Actually, the performance for loading images on graphics 2.0 and 1.0 is largely the same. What’s different is when the image is loaded:
- The 2.0 engine lazily loads the image when it’s actually going to be visible on screen (e.g. alpha > 0, etc), which is ideal for applications that want faster start up times by deferring the cost of large image loads.
- The 1.0 engine immediately loaded textures on the display.newImage() call regardless of its visibility on screen. This meant you paid the penalty for large image loads immediately.
The work around to this to force the 2.0 engine to load the texture immediately is to load a tiny display object on start up.
Attached is a sample project, where you will notice that we load a large image (alpha value at 100%) but the height and width is tiny (sub-pixel) so it can’t be seen. The actual display object (background) that will use this texture however is not visible until 5 seconds into the application. This causes the engine to load the texture immediately on start up and there is no extra load incurred while the text is transitioning across the display.
Longer term, we are working on a solution to allow a more immediate load for textures in the 2.0 engine but thought this would be useful to explain both the change, and how to immediately load textures on start up.
This is a big change and not one I was aware of. It will cause all sorts of headaches.
OK. That explains why I was getting these temporary hangs after implementing G2.0 every time I started an app.
I didn’t want to modify all the image loading in every module within my apps, so to solve this problem (I hope temporarily) I created a small module with overridden functions that force a load.
-- -- override.lua -- local saved = {}; saved.newImage = display.newImage; display.newImage = function(...) local forceLoad = saved.newImage(select(1, ...)); forceLoad.width, forceLoad.height = 0.1, 0.1; timer.performWithDelay(100, function() forceLoad:removeSelf(); end); local img = saved.newImage(select(1, ...)); return img; end saved.newImageRect = display.newImageRect; display.newImageRect = function(...) local forceLoad = saved.newImageRect(select(1, ...)); forceLoad.width, forceLoad.height = 0.1, 0.1; timer.performWithDelay(100, function() forceLoad:removeSelf(); end); local img = saved.newImageRect(select(1, ...)); return img; end
The only thing that needs to done after this is to put require(“override”) at the top of main.lua.
I tested this on some projects and it seems to work well. The initial lag I saw was gone.
It’s not pretty, but it’s functional…
To take Bryan’s sample app it would become:
-- -- main.lua -- require("override") local imageToLoad = "boxer-1920.jpg" local background = display.newImage( imageToLoad, display.contentCenterX, display.contentCenterY ) background.alpha = 0 -- Without the "override" step the image in background isn't loaded until it becomes visible local myText = display.newText( "Moving text!", 0,0, native.systemFont, 40 ) myText:setFillColor( 1, 255/255, 255/255 ) transition.to( myText, { time=10000, x=320, y=480 } ) local function test() background.alpha = 1 background.x = 0 end timer.performWithDelay( 5000, test)Similarly, we’ve just converted one of our games to Graphics 2.0 for launch on the GameStick and are seeing a large drop in performance. The version shown has extra particles so is running slower than normal but it shows the drop well:
Previous version:
https://www.dropbox.com/s/jvil9uoo6o0vmvc/Graphics_1-0_h.jpg
With Graphics 2.0:
https://www.dropbox.com/s/fgl7coql6tl9vfr/Graphics_2-0_h.jpg
So about 30% slower for us too.
The game needs to run at close to 60fps to be playable and I’m worried that we’re just not going to hit that with Graphics 2.0.
After seeing the demo of 5000 fish at 60 fps we were really hoping for a big boost in performance so this has come as a bit of a shock. Or maybe we’re doing something wrong with our rendering? Tips welcome.
Please can Corona Labs share the 5000 fish demo so we can test the performance of it on a GameStick?
Thanks,
Ian
So it appears that the initial freezing issue has been identified, but as other people have said, there seems to be about a 30% drop in overall performance as well. It doesn’t seem like these are related, although they could be. It seems that this performance loss is associated with moving/rotating large images. Does that concur with what you’ve seen spideri and Nick?
Well our game Finger Hoola is 90% about rotating images so that would be consistent… and annoying if it were true. Hopefully you’ve identified a problem that can be resolved though.
Yep, XWL you nailed it. I’ve stripped down things to barebones and just generally speaking things aren’t as efficient as they were before the g2 upgrade. Luckily, I’m going to continue using build 1260 as it has everything I need for the time being.
Hopefully, this will get sorted out. I’m not even going to entertain the work around given as that wasn’t needed before, so why start now :)-
-nick
So in a future build will there be some sort of flag we can toss in at the top of our lua files
display.FastLoadTextures = true
…or something 
double
triple :) :)
MEGA SMILEYS :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)
What devices are you guys testing on?
LKinx in IRC narrowed down a huge performance hit to rotating a couple of sprites. I don’t recall the specifics, but thought I’d throw it out there as it is something others have noticed as well.
A GameStick still…
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.