Why is writing to the framebuffer a FACTOR slower than reading from the framebuffer ??.
To be more precise: Reading about 1Mb pixel data from the framebuffer takes about 10 ms,
while writing the same amount of data takes about 400 ms. These figures are measured on
a standard PC 1.6 GHz running Windows/XP.
I dont understand why writing is about 40 times slower than reading.
Below is a list of some of the essential lines of code. Note that the viewport is 644*488.
float time1 = (float)watch.Stop();
float time2 = (float)watch.Stop();
(time1 = 10, time2 = 400)
Write frame buffer operation is VERY slow because
is blocks a grafics pipeline.
Why do you need to write to a frame buffer directly?
Yoy may render to texture of use offscreen buffers
I was using the accumulation buffer to perform antialiasing of the hole scene. I noticed the poor performance of this operation. It takes about 4 seconds to carry out 8 accumulations. I then made some calculation showing that this operation should take less than 0.5 second, if carried out by my own implementation.
estimate = 1e-9*(cycle number)45125128 = 0.4
cycle number = 50 (optimistic)
This estimate was based on the assumption that read and write operations to the framebuffer was done in “normal” speed.
If you want to replace the accumulation buffer by something hardware accelerated on your hardware, try pbuffers with render to texture (or just glcopytexsubimage).
It works pretty fast, see my website for a real motion blur over 12 rgba 512x512 samples at 37 fps on my geforce3 :
DrawPixles doesn’t stall the pipeline. Try BGRA format for your source data, it is generally the internal format of most PC graphics cards…