LWJGL 3 - Why does drawing sprites take so much performance?

Started by mrdlink, March 03, 2018, 11:26:50

Previous topic - Next topic

mrdlink

@Spasi
But what would be the best methods to apply to a 2D application? Depth testing I think is no option, and occlusion culling is kind of hard to apply since partial transparent sprites still have a quadratic geometry. In my last application I already sorted my sprites for materials, shaders and render order (back to front, opaque first and then transparent) because alpha blending is an essential part if you want to draw 2D only.
I would have tried to do front-to-back rendering for opaque sprites, but unfortunately you can't get the current pixel color in the fragment shader.
What else could be a good practice?

spasi

I can't give specific advice without seeing a real application and what it does. But, depth testing can work nicely, even with 2D rendering. Sort opaque or alpha-tested sprites front-to-back, enable depth writes, enable depth-test. Disable depth writes for blended sprites, but keep depth-test enabled. You'll save bandwidth on any overlapping sprites.

But I really think you shouldn't make any assumptions about performance based on this test. A real application with 2D rendering, with normal sprites without that much overdraw (i.e. smaller sprites, distributed evenly across the screen, with enough overlap to make it interesting) would not have this performance profile. The bottleneck would be elsewhere (usually render command submission).