I know that many of you are waiting for a performance update for Starling (fueled by an article from Ville Koskela). Some of you even donated for that cause! Thanks again for that! =)
During the last weeks, I've done several experiments on that issue (including countless hours of iOS release mode compilations *g*). And now, finally, I can share the results with you!
On GitHub, you'll find a new branch with the modified Starling version. Since it will break some existing code, I haven't yet merged this version with the master tree; this will be done when I finish the release candidate of Starling 1.4 (which will be within the next 2 weeks).
In any case, while the "50%" promised by the article were somewhat exaggerated, it's still quite a welcome performance boost. My tests indicate about 20-25% more speed:
(Disclaimer: the numbers are results of the Starling benchmark in the Demo project; however, the displayed object was scaled down to 25% with activated mipmaps to rule out fillrate limitations of the GPUs.)
In real games, it won't be that much, of course. There are many factors that contribute to the performance of a game, including the GPU's fill rate, your own code, the number of draw calls, etc. Still, it never hurts to have some more resources at your hand, right?
For those interested in the technical background: the new branch uses byte arrays to upload vertex data to the GPU. (Thanks to tsangwailam for the suggestion!) Furthermore, color data is stored in only 8 bytes now instead of 32.
ByteArrays can be uploaded to the GPU much faster than Vectors; however, they are also relatively slow to write to and read from, which swallows up some of the gained performance. If Adobe makes this faster in future AIR versions, we could expect even higher performance. (Before you ask: no, domain memory cannot be used with Starling's current architecture. I tried that.)
In any case, this change requires small changes in any custom display objects you have created.
(a) Uploading data to a vertex buffer:
// previously: mVertexBuffer.uploadFromVector(mVertexData.rawData, 0, numVertices); // now: mVertexBuffer.uploadFromByteArray(mVertexData.rawData, 0, 0, numVertices);
(b) Setting the color attributes on the context
// previously: context.setVertexBufferAt(1, mVertexBuffer, VertexData.COLOR_OFFSET, Context3DVertexBufferFormat.FLOAT_4); // now: context.setVertexBufferAt(1, mVertexBuffer, VertexData.COLOR_OFFSET, Context3DVertexBufferFormat.BYTES_4);
As you can see, those changes are easy to make, so any existing code should be updated easily.
Let me know what you think about this! I hope you like that little enhancement.