GDI + Amazing decoding speed and awful pull speed!
Thanks for the answers, in fact I'm not puzzled by anything 1024 * 768 pixels slower than 100 * 100 pixels ... It's so simple logic .. What puzzled me is that the DrawImage interpolation algorithm can be very slow, while there are many better algorithm and its decoder seems to be able to decode from jpg at a certain resolution, this is really great, I once searched but could not find a free lib for this ...
This is really weird! I will add the following code to the Paint method. c: \ 1.jpg - 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 very fast! even in real time! I don't think decoding a 5MHz 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 is getting very slow
// --------------------------------------------- --- --------------
If I add Bitmap = Bitmap :: FromFile (L "c: \ 1.jpg", true); // to the construction
leave
Graphics graphics(hdc);
graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
graphics.DrawImage(bitmap,0,0,2000,2000);
in the OnPaint method, The code is still a little slow ~~~
// --------------------------------------------- --- ------------------
Compared to decoding, the drawImage process is really slow ...
Why and how did they do it? Did Microsoft pay men to take responsibility for double the decoder's salary than men who take responsibility for drawing the picture?
source to share
You don't need to decode the JPG if you reduce the ratio by 8 times. JPG images are composed of 8 by 8 pixel blocks, DCT-transformed. The average of this block is a factor of 0.0 DCT. Thus, decreasing the factor of 8 is simply a matter of releasing all other components. Scaling even more (for example 4000-> 200) is just scaling down from 4000 to 500 and then scaling usually from 500 to 200 pixels.
source to share
It is possible that decoding will be delayed until needed. This is why it is so fast.
Perhaps on a 200x200 package, GDI + only decodes enough 200x200 and 2000x2000 draw blocks, they decode more.
Graphical routines always contain some obscure optimizations that you will never know.
Perhaps Reflector will tell you?
source to share
Just guess, but can you try painting from 4000x3000 or 2000x1500? Perhaps the fact that 4000 and 3000 are divisible by 200 makes everything faster and 3000 is not divisible by 200 slows it down (although that would really be weird).
Typically do some profiling or timing. If 2000x2000 is about 100 times slower than 200x200, you're fine. And don't worry if 2000x2000 is too slow. If your screen is 1024x768, you cannot see the whole image, so it’s better to select the part of the image that is visible on the screen and draw it, 1024x768 is 5 times faster than 2000x2000.
source to share