GDI+ 's Amazing decode speed, and terrible draw speed!

Question

---

Thanks for answers，Actually I am not puzzled about draw 1024*768 pixels is slower than 100* 100 pixels... It is so simple a logic.. Which made me puzzled is that DrawImage's interpolation algorithm may be very slow, while there exists lots of better algorithm, and its decoder seems can decode from a jpg with a certain resolution, it is really cool, I search for sometime but do not find any free lib to do this...

It is really strange! I add the following code into on Paint method. c:\1.jpg is 5M jpg file, about 4000*3000

//--------------------------------------------------------------

HDC hdc = pDC->GetSafeHdc();
bitmap = Bitmap::FromFile(L"c:\\1.jpg",true);
Graphics graphics(hdc);
graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
graphics.DrawImage(bitmap,0,0,200,200);

The above is really fast! even real time! I don't think decode a 5m JPG can be that fast!

//--------------------------------------------------------------

HDC hdc = pDC->GetSafeHdc();
bitmap = Bitmap::FromFile(L"c:\\1.jpg",true);
Graphics graphics(hdc);
graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
graphics.DrawImage(bitmap,0,0,2000,2000);

The above code become really slow

//--------------------------------------------------------------

If I add Bitmap = Bitmap::FromFile(L"c:\1.jpg", true); // into construct

leave

    Graphics graphics(hdc);
    graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
    graphics.DrawImage(bitmap,0,0,2000,2000);

in OnPaint method, The code is still a bit slow~~~

//------------------------------------------------------------------

Comparing with decoding, the drawImage Process is really slow...

Why and How did they do that? Did Microsoft pay the men taking charge of decoder double salary than the men taking charge of writing drawingImage?

Answer 1

So, what you're really wondering is why

graphics.DrawImage(bitmap,0,0,200,200);

is faster than

graphics.DrawImage(bitmap,0,0,2000,2000);

Correct?

Well, the fact that you are drawing 100 times more pixels in the second case could have something to do with it.

Answer 2

It could be possible that the decoding is deferred until needed. That's why it is so fast.

Maybe on the 200x200 case GDI+ only decodes enough blocks to paint 200x200 and on 2000x2000 they decodes more.

Graphic routines always contains some obscure optimizations, you could never know.

Maybe Reflector will tell you?

Answer 3

Just a guess, but could you try drawing with 4000x3000 or 2000x1500? Perhaps the fact that 4000 and 3000 are divisible by 200 is speeding up the whole and 3000 not being divisible by 200 slows it down (although this really would be weird).

Generally, do some profiling or time measurement. If 2000x2000 is about 100 times slower than 200x200, everything is okay. And don't bother if 2000x2000 is too slow. If your screen is at 1024x768, you can't see the whole image, so you better pick the part of the image that is visible on the screen and draw it, 1024x768 is 5 times faster than 2000x2000.

Answer 4

You don't need to decode JPGs if you're scaling down by a factor of 8. JPG images consist of blocks of 8 by 8 pixels, DCT-transformed. The average value of this block is the 0,0 coefficient of the DCT. So, scaling down a factor of 8 is merely a matter of throwing away all other components. Scaling down even further (eg 4000->200) is just a matter of scaling down from 4000 to 500, and then scaling normally from 500 to 200 pixels.