A quick thought for today evening:
Pushing 36,000KB of data from VRAM to RAM per second by means of doing 180 glReadPixels() calls per second is a bad, bad idea..
*gasp*. I’ve always known that reading pixels off a color buffer of either type of FBO is not the gentlemen’s way of behaving, but – to be honest – it’s the first time I’m hitting the dreaded bus throughput problem. The issue I’m getting is that the rendering output appears jerky and the jittering appears to be happening in rather random delays. Yes, random enough to ruin the whole smooth experience 🙂 Oh well, with 60 FPS set as the desired frame-rate, it was bound to happen.
Problem is, CamMuxer is already complex enough for such a little pet project I intended it to be at the beginning, but looks like there’s no other way to overcome performance bottlenecks I’m seeing but by introducing PBOs to the pipeline, making the solution even more twisted than it already is.
Funny thing about it is that the jerky updates come into play only if you start moving the cursor around. My guess is that it could have something to do with more frequent, system-enforced context switching occuring due to necessary window repaints. May it be that Microsoft might have finally started to hardware accelerate GDI with the advent of Windows 7?