General rendering and performance questions (OpenGL)

Question

I'm working with LibGDX, and I need answers to some general optimization questions:

1. If I draw a sprite that is only partially visible to the viewport/camera, does it have the same performance hit as drawing it completely visible to the viewport?
2. If I draw a sprite outside the boundaries of the the active viewport, does it affect the performance same way as not drawing the sprite at all OR similar to drawing it inside the viewport? In other words: What kind of performance impact off-screen sprites have?
3. When drawing a small (for example 32x32) region of a large TextureAtlas (2048x2048) on the screen, does it have a similar performance hit as drawing a small 32x32 single texture? I know that large textures affect memory usage, but do they affect real-time rendering performance when rendering only a small region?
4. If I rotate a big sprite while rendering it, does it affect performance?
5. If I draw a 4096x4096 texture on the screen, but scale it down so that on the screen it looks like 10x10, does it have the same performance as rendering it full sized? i.e. does the apparent size of a texture on the screen affect rendering performance?

Answer 1

1. No.
2. Its more permormant than drawing it inside the viewport, but still not as performant as not drawing it at all.
3. The bigger image will take more time to be prepared for rendering. The actual rendering will be the same as fast.
4. Yes.
5. No.

Answer 2

1. No. Vertex processing will be the same, but the fragments outside the viewport will be clipped, reducing fragment processing.

2. This is just an extreme case of question 1. Now there's no fragment processing, but still all the vertex processing. Depending on how cheap/expensive your vertex processing is, this can be very variable. It's certainly more than not drawing at all. On the other hand, if you add a lot of logic in your app to avoid drawing a sprite, you may be adding more overhead than you save by not rendering it.

3. Once the texture is loaded, the rendering itself should be fairly similar. But of course loading the texture is going to be much more expensive. This is not only for the OpenGL call you make to load the texture data, but also the overhead to map it into the GPU address space before rendering, and other related memory management overhead.

4. Maybe. But probably not much. GPUs use memory layouts that are optimized for local access, without much dependence on the orientation of the access pattern.

5. Rendering at 10x10 is certainly much cheaper because there are a lot fewer fragments, and corresponding sampling operations. But it can still be much more expensive than rendering with a 10x10 texture, because access is much less localized, so there will be a lot more cache misses. To avoid that, use mipmapping, which will give you most of the performance of a smaller texture if you render a large texture scaled down.

Answer 3

When talking about performance, the impact depends on what your bottle neck is. Drawing a sprite uses some CPU and a tiny bit of GPU regardless of how much, if any, of it is on screen. In general, the more pixels of a sprite are actually on screen, the more GPU it will use.

1. In terms of CPU, no difference, but for the GPU, drawing fewer pixels of the sprite is better.

2. Off screen sprites have a CPU impact and small GPU impact. If you have a lot of off screen sprites, you may need to avoid drawing them, but you should check them in groups instead of one-by-one, or you risk spending more CPU to check them than it would take to draw them off screen.

3. Drawing a small region of a big texture has same performance hit as drawing a small texture. But the first option allows you to batch a lot of different images into one draw call, which is a big saver.

4. Some, because you'll recalculating its vertices on each frame.

5. Drawing it smaller means you're drawing fewer pixels, so that's faster.