Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It is general wisdom that you redraw the entire viewport on each frame.

I would like to use partial updates; what are the various ways can do that, and what are their pros, cons and relative performance?

(Using textures, FBOs, the accumulator buffer, any kind of scissors that can affect swapbuffers etc?)

A scenario: a scene with a fair few thousand visible trees; although the textures are mipmapped and they are drawn via VBOs roughly front-to-back with so on, its still a lot of polys. Would streaming a single screen-sized texture be better than throwing them at the screen every frame? You'd have to redraw and recapture them only on camera movement or as often as your wind model updates or whatever, which need not be every frame.

share|improve this question
How many polygons per object? How many draw calls? How many VBOs? How are the VBOs updated? Are you using any shaders? How many state changes? How many textures per object? Are you doing frustum culling? How much memory do you have? How big is the screen? – user744 Jan 13 '11 at 18:13

Do not try to keep anything persistent in the window's framebuffer. For example, graphics cards usually maintain a hierarchical z-buffer that only works if you call glClear regularly. If you have a rarely redrawn background, I suggest you render that into an FBO (or PBUFFER, if you lack proper FBO support with MSAA) when it changes. If the background drawing takes very long, you can even spread it out over multiple frames and smoothly blend over. That's a technique that's often used for very expensive skyboxes with lots of atmospherical effects.

share|improve this answer
+1 for good advice, but I still have trouble believing this is a problem in this case. – user744 Jan 13 '11 at 12:15
As I said, it's a technique that's used for very expensive athmospheric scattering effects, which would otherwise slow you down considerably. At least with an "open" scene, like a terrain or something else where a lot of sky is visible, these techniques can burn a whole lot of fill-rate. – ltjax Jan 13 '11 at 12:20

There is a MESA extension to do this, glXCopySubBufferMESA. As buffer swaps are platform-dependent, any partial buffer copy is also going to be.

Although, the obvious question is, what are you tackling where you think such a thing may help?

share|improve this answer
very localised particle effects on a beautiful but rarely-redrawn background, fwiw – Will Jan 12 '11 at 14:17
And are you actually having any speed concerns you think damage tracking might fix? – user744 Jan 12 '11 at 14:31
commenting out the code to draw the backdrop each frame doubles frame-rate. So of course its natural to think about reusing those pixels rather than regenerating them when the camera doesn't move. – Will Jan 13 '11 at 7:29
When you say "backdrop" do you mean a couple of quads or a 3D scene? When you say "doubles the framerate" do you mean 500 to 1000 or 30 to 60? If it's a 3D scene and static, did you store it in a VBO? Unless it's tens of millions of polys I can't see it making a difference. – user744 Jan 13 '11 at 12:03
By asking about partial updates, rather than "How can I render a lot of static geometry from a static view quickly?", you actually made the question too specific, not too general. – user744 Jan 13 '11 at 15:05

I'd have to agree with JoeW further up, the question seems to be too specific, in that you state you want to solve the performance problem of lots of trees, but the question states only by partial updates and that leaves only to solutions based around that.

What you don't seem to mention above is any form of LOD on the mesh, just mip-maps for the textures. When I've needed to make sure lots of tree's have to be drawn on screen I'd have at least two polygon mesh LOD's for them and in the distance have that go down to a simple forward facing sprite (we've used a bit of a hybrid solution where we also use SpeedTree which does pretty much the same thing). I guess it comes down again to where the bottleneck is and until you understand exactly what it is that's slowing it down the most you can't really optimize that area.

Just in case by FBO you didn't mean 2D Imposters I've also thrown a link in for that. I've not shipped anything using them dynamically myself but I know titles have with success, it all depends how much video memory you have free on your target platform to implement.

share|improve this answer

I think you should always compose the final image completely, but you may keep parts of it in auxiliary buffers.

In other words, let's say you have some very complex HUD. Render that to a separate texture with everything see-through masked with alpha. You don't need to update the HUD texture every frame, only whenever it actually needs to be updated.

When rendering a frame, you just re-use the HUD texture each frame.

This was just an example, the same principle could be applied to other things that do not require update each frame.

The only place where I think updating only parts of the screen would help are extremely platform-specific to some obscure low-end hardware, and OpenGL doesn't really apply there. Everything else more or less requires the full screen update (either due to double buffering, tiling, or whatever weird NDS did again).

share|improve this answer
As ltjax said, this technique works, but it burns through fill rate and memory. Both are far more limited than triangle counts and usually also more limited than bandwidth for sending vertices - which can be mitigated for a complicated static scene by using VBOs anyway. – user744 Jan 13 '11 at 14:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.