Textureswitching, Spritesheets, Performance, Static 'sprites', TextureAtlas -- the graphics pipeline

Solar2D General Questions/Discussion
#1

Hi guys,

Can someone tell me some more about the graphicspipeline in corona?

How are textureswitches handled
How are multiple draw calls handled / buffered?

What I’d like to know is wether corona does smart textureswitching (no switching if it’s not necessary), and wether draw calls with the same GL-state (texture etc) are buffered, so they result in only one GL call?

Also, I’d like to know how I am supposed to handle static images.
I would like my static images to come from a spritesheet (better name would be TextureAtlas)

IMO the naming of some of the classes is wrong…
A TextureAtlas would be a texture containing multiple textures to be reused by either sprites or static images.
Ideally, I’d like to see display.newImage(textureAtlas, “indexName”), which would return an object which would behave like a normal image.

This would also help against some weird stuff in ui.lua, where I see some ulgy hacks for retina displays. [import]uid: 5942 topic_id: 16849 reply_id: 316849[/import]

#2

I second that - I also have the feeling that the documentation is lacking in this respect (I mean, even the powers of 2 texture size implications aren’t immediately obviously explained under the image docs), and that there must be performance gains to be made with a clear understanding of draw call structure. Perhaps a more ‘tech under the hood’ section of the documentation would be nice. [import]uid: 70134 topic_id: 16849 reply_id: 63092[/import]

#3

As a former cocos2d developer, I recommend ansca to take a look at how cocos2d has done some of the stuff.
It’s really clear in terms of what happens, and clear in terms of class-names.
[import]uid: 5942 topic_id: 16849 reply_id: 63094[/import]

#4

As a former cocos2d developer, I recommend ansca to take a look at how cocos2d has done some of the stuff.
It’s really clear in terms of what happens, and clear in terms of class-names.
[import]uid: 5942 topic_id: 16849 reply_id: 63095[/import]

#5

Any update on this?
Running into some serious performance issues [import]uid: 5942 topic_id: 16849 reply_id: 91738[/import]

#6

(Thank Peach for bringing this to our attention)

See: http://blog.anscamobile.com/2012/03/image-sheets-image-groups-and-sprites/

You can create static images from “image sheets” (a.k.a. texture atlases).

You can also optimize draw calls via image groups, for objects using the same image sheet.

We’re seeing the biggest performance boost from offscreen culling, which avoids submitting to OpenGL altogether. This applies to older API’s as well as the newer ones that rely on image sheets.

We’re also seeing bigger boosts on older phones like iPhone 3GS. [import]uid: 26 topic_id: 16849 reply_id: 92014[/import]

#7

Yep… I read it today, and implemented it.
Came across some bugs, but worked around those.

Very happy with the progress corona is making the last couple of weeks.

Next: gl calls :wink:

Maybe lime is getting up to speed as well. [import]uid: 5942 topic_id: 16849 reply_id: 92018[/import]

#8

@walter: up until now I’ve sort of been doing offscreen culling myself, by updating objects’ coordinates but only drawing them if they are within the screen bounds. With the new automatic offscreen culling, can I safely assume that I don’t have to handle this myself anymore? [import]uid: 120 topic_id: 16849 reply_id: 92058[/import]

#9

@bryan.vaccaro Yeah you should be safe to do that. :slight_smile:

Also it would be interesting to hear the performance difference, maybe you could run your app with your code and report the fps it runs at, then comment out your culling routine check the fps and post up both results? [import]uid: 84637 topic_id: 16849 reply_id: 92136[/import]

#10

Good idea Danny, here are the results:

The test consists of 200 displayGroups being spawned, with 100 of them containing 4 images and 100 of them containing 5 images and a mask.

I used the fps counter from the code section and kept an eye on the frame rate.

The groups bounce around the screen using object:translate(), and rotate around their center by setting object.rotation. (The last time I checked using M.Y. Developers Profiler, translate() is faster than setting the x and y properties but rotate() was slightly slower than just setting the rotation property)

I tried a few things with the culling routine. One method sets object.isVisible = false when the object leaves the stage, but keeps updating the cached coordinates, and sets isVisible = true when it re-enters the stage. I didn’t know if that would change how the graphics are handled behind the scenes, so it was just an experiment. It didn’t seem to have much of an impact either way.

The other method was to remove the display group entirely and set it to nil when it leaves the stage, but keep updating the coordinates and recreate the display group when it re-enters the stage. That seemed to have a positive impact on the framerate but I think recreating the display groups is costly when you have ~100 of them re-entering the stage at the same time.

build 750

culling:
isVisible = 30 avg, 20 min
make group = between 30-60, 20 min
no culling = 30 avg, 20 min
build 762:

no culling = 30-60 but seems to stay around 60, 30 min

with the fps counter disabled, I can spawn well over 200 and it still seems to be smooth. It’s definitely fast, although the “set it and forget it” approach is going to take some getting used to :slight_smile:
I’ll try to do some tests with the Profiler as well to see how many ms the drawing routine is taking, but I don’t think that can trace automatic offscreen culling.
edit: also note, I’m being sloppy right now and none of the images being used are in spritesheets or imagesheets and none of them are powers of 2, so that probably adds to the overhead. I think moving to physics for movement + imagesheets for the graphics will really make things fly. [import]uid: 120 topic_id: 16849 reply_id: 92219[/import]

#11

@byran : Nice so it appears letting corona handle all culling results in much better performance given your comparison.

Also less for people to worry about :slight_smile:

Thanks :slight_smile: [import]uid: 84637 topic_id: 16849 reply_id: 92239[/import]