GDI+ 惊人的解码速度和可怕的绘制速度！
感谢您的回答，实际上我并不困惑绘制 1024*768 像素比 100* 100 像素慢...这是一个如此简单的逻辑.. 让我困惑的是DrawImage的插值算法可能很慢，而有很多更好的算法，而且它的解码器似乎可以从一定分辨率的jpg中解码，真是酷，我搜索了一段时间但没有找到任何免费库可以做到这一点...
这真的很奇怪！ 我将以下代码添加到 Paint 方法中。 c:\1.jpg为5M jpg文件，约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);
以上真是快啊！ 甚至实时！ 我不认为解码 5m JPG 能那么快！
//------------------------------------------------ --------------
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);
上面的代码变得非常慢
//---------------------------- ----------------------------------
如果我添加 Bitmap = Bitmap::FromFile(L"c:\1 .jpg”，正确）； // 进入构造
并留
Graphics graphics(hdc);
graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
graphics.DrawImage(bitmap,0,0,2000,2000);
在 OnPaint 方法中， 代码还是有点慢~~~
//------------------------------------ ----------------------------
与解码相比，drawImage 过程真的很慢...
他们为什么以及如何做到这一点？ 微软给负责解码的人支付的工资是负责写绘图的人的两倍吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
那么，您真正想知道的是为什么
比
Correct 更快？
事实上，在第二种情况下，您绘制的像素多了 100 倍，这可能与此有关。
So, what you're really wondering is why
is faster than
Correct?
Well, the fact that you are drawing 100 times more pixels in the second case could have something to do with it.
如果缩小 8 倍，则无需解码 JPG。JPG 图像由经过 DCT 转换的 8 x 8 像素块组成。 该块的平均值是 DCT 的 0,0 系数。 因此，缩小 8 倍只是扔掉所有其他组件的问题。 进一步缩小(例如4000→200)只是从4000缩小到500，然后正常地从500缩放到200像素的问题。
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.
解码有可能被推迟到需要时。 这就是为什么它这么快。
也许在 200x200 的情况下，GDI+ 只能解码足够的块来绘制 200x200，而在 2000x2000 的情况下，它们会解码更多。
图形例程总是包含一些你永远无法知道的晦涩的优化。
也许 Reflector 会告诉你？
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?
只是猜测，但是您可以尝试使用 4000x3000 或 2000x1500 进行绘图吗？ 也许 4000 和 3000 能被 200 整除的事实正在加速整体的速度，而 3000 不能被 200 整除的事实会减慢速度（尽管这确实很奇怪）。
一般来说，进行一些分析或时间测量。 如果 2000x2000 比 200x200 慢约 100 倍，则一切正常。 如果 2000x2000 太慢，也不必担心。 如果你的屏幕是 1024x768，你看不到整个图像，所以你最好选择屏幕上可见的图像部分并绘制它，1024x768 比 2000x2000 快 5 倍。
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.