I have an application that needs to display JPEG images at a high rate of speed. It gets these in a stream from a server and displays them as a "moving" image. It also needs to get simple JPEG images to display as still frames.
The most obvious solution seemed to be to get the bytes of the JPG-format images as they arrive and convert them to a StdPicture for display in an Image control, etc.
This works great, but when I looked at optimizing to use less CPU I found that a single statement, a single API call, was the very hottest in the program.
So I created a tiny case case Project. Here I just load a Byte array from a .JPG file then call this function in a loop 100 times:
First question: I assume (falsely?) that OleLoadPicture() calls use GDI to decompress JPEG images.
Second question: If true I wonder if calling GDI+ to decompress into a bitmap then wrapping that in a PICDESC and calling OleCreatePictureIndirect() would be faster?
I know that GDI+ historically was slower than GDI at this based on benchmarks I saw in many web pages. But then starting in Vista Microsoft tried to change GDI+ to make use of available hardware acceleration, perhaps newer CPU instruction sets, and other tweaks to speed things up.
For all I know you need to select GDI+ 1.1 (via an application manifest) to get the new enhancements. So let's just leave that aside and focus on the default GDI+ 1.0 most people use.
Opinions? Anyone have working code on hand to create another class similar to my DecodeGdi (call it DecodeGdiPlus or somethng) so a comparison might be run?
For all I know the real answer would be to use DirectX, but I'm not sure that will address the single still image case anyway.
The attached archive is only large because of a sample image file.