Windows Superfast Screenshots (GL)

[Baker]

[taniwha]

25ms for 1680x1050, rgb. that's ~200MB/s. It would probably be faster if I used rgba or even bgra (or whatever the native format is). I'm not sure I'd call that sluggish. It's certainly enough for 40fps (neglecting other factors such as rendering, compression, etc).

Actually, I just checked, and using RGBA instead of RGB drops glReadPixels from 25ms to 21ms.

Note, however, that the rgb to bgr swap in SCR_ScreenShot_f takes about 10ms on my system. So that's 35ms for screen shot, not including writing the image.

(G80 [GeForce 8800 GTS], nvidia driver, linux, (R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz)

[Spike]

presumably glReadPixels would have the same format performance characteristics as lightmaps. specifically that you should be grabbing the data as bgra instead of rgb - format GL_BGRA, type GL_UNSIGNED_INT_8_8_8_8_REV. Assuming that's how your backbuffer is configured anyway.

when you time it, what is it that you're timing? the implicit glFinish() call that is part of glReadPixels()? certainly a windows call will bypass that, but you'll end up receiving stale image data. Certainly this is significant if you've a mod sending screenshot stuffcmds to capture the scoreboard.

[taniwha]

Actually, I put in an explicit call to glFlush before the call to Sys_DoubleTime, and it didn't make any difference.

I agree that GL_UNSIGNED_INT_8_8_8_8_REV would probably be faster still.

[metlslime]

I think the slowest part of taking a screenshot is actually finding an available filename; once you have 50-100 existing screenshots the directory scan really bogs down. I'm sure there's an obvious better way but never got around to fixing it.

[Baker]

Not all ideas work out. I know where to file this one now.

[mh]

glReadPixels (and glDrawPixels) have the exact same characteristics as textures, as Spike noted. Grab them in their native format and you get better performance (you still have a pipeline stall which can be up to 3 frames, but it doesn't get much worse). It's probably going to be much faster to compress down to BGR (for TGA output) in-place following that.

Grabbing a free file name is likely the slowest part of the process though (aside from disk I/O which you can do nothing about - that's already optimal). A FindFirstFile/FindNextFile loop is probably going to be better than just trying to fopen each file in turn as all it would need to do is access the filesystem tables (rather than set up all the crap needed for full-on file I/O) but I haven't benchmarked this. On Windows fopen will be just a wrapper around the native CreateFile call, so using CreateFile directly may help by bypassing the wrapper (any perf improvements will be quite marginal though). Failing that, access (or _access on Windows) is something that's supposed to be pretty good.