Performance, compiled sprites.

niksan

Getting back into the swing of things over the festive period I thought I'd have a dabble in writing my own rendering code then started to get a bit obsessed with performance in regards to VBOs (compiled sprites). I'll start off by posting some numbers.

=================================

glDrawElements(GL_TRIANGLES,...

30.7% - EAGLContext presentRenderbuffer
21.7% - SPDisplayObjectContainer
9.9% - SPQuad
5.8% - TiledMap
4.6% - SPImage

=================================

glDrawElements(GL_TRIANGLE_STRIP,...

33.6% - EAGLContext presentRenderbuffer
19.7% - SPDisplayObjectContainer
8.5% - SPQuad
5.3% - TiledMap
3.8% - SPImage

Now, GL_TRIANGLE_STRIP was using degenerates for each quad 6 indices, either end indices duplicated just like compiled sprite does, now I'm not sure if I'm reading instruments incorrectly, but it would suggest a triangle list is quicker to render than a degenerate strip that degenerates every quad. Or does presentRenderbuffer cause a vysnc so the bigger number the better?

Does anyone actually make heavy use of compiled sprites which they could test changing over to triangle lists, it's only a 3 line change but I'm interested in results, unless someone has already profiled. I'm guessing presentRenderbuffer uses some immediate mode as well as it seems a lot to kick off a render list, and it's (on an iPod 4th gen at least) eating a third of cpu cycles.

Anyway, I'd appreciated if anyone could clarify / shed some light on the above as I'm enjoying playing around with this at the moment. 🙂

niksan

Wow, seems you can actually get presentRenderbuffer down to 27% by disabling GL_BLEND (always on by default), not only that, I found for a 20x30 (16x16) tiled map, I saw the following figures for device utilisation.

With GL_BLEND:

48% Device
42% Renderer

Without GL_BLEND:

30% Device
24% Renderer

Sorry if this is almost like it's turning in to a blog post, but it seems if you're drawing opaque images, normally for backdrops, you can increase your performance by splitting things like backdrops, draw those with GL_BLEND disabled, then re-enable and carry on as normal. If you're doing a tiled map renderer you can double render performance.

The jury is still out in regards to tri-list vs tri-strip.

Any other optimising tips would be appreciated as well. 🙂

TTStu

Hi thanks for sharing niksan, erm, using the default Sparrow implementation, how would one go about disabling GL_BLEND selectively?

soule

Hey, my game uses tilemaps (_600-1000 tiles at a time rendered, 16x16) and compiled sprites. I can test if you like 🙂

Daniel

Yes, turning off blending can be a huge performance benefit -- Sparrow 2.0 will allow you to set a blend mode per object, and thus make use of it. Hang on =)

niksan

@soule you can search the code base for glEnable(GL_BLEND) and temporarily change it glDisable and run via instruments. I really recommend using instrument a lot, I didn't realise I had a rogue SPQuad set to full screen sat underneath my tiled map renderer was some overspill from a previous test, and it doubled draw time.

Unfortunately you don't seem to be able to disable GL_BLEND via a VAO unless I'm doing it wrong. 🙁

@Daniel, you keep dangling that carrot but I'm not biting anymore. 😉

Daniel

Niksan, I totally understand. 🙈

niksan

Did this ever make it in Daniel?

Daniel

Yes! As promised, Sparrow 2.0 (and 2.1) contains a new "blendMode" property.

To disable blending altogether, use the following code on a display object, e.g. on a background image without transparency:

object.blendMode = SP_BLEND_MODE_NONE;

In 2.1, this will lead to a faster performance. (2.1 will be out in the next days.)
In 2.0, this will just deactivate the transparency, though. 😉