StretchBlt slow, can I use directx somehow?

[revg75]

Hi,

I have a constantly changing 300x216 byte array which contains a bitmap essentially. It is actually a CDG (karaoke) file streaming in. So each time I get the bitmap data it is changing. I won't want to display it at 300x216, I want to display it at 1024x768, so I use a call to the GDI stretchblt function (this is called constantly as I receive the bitmap data), but it is very slow. CPU usage jumps very high when stretching this 300x216 image to 1024x768 using this method. Whne I use bitblt at 300x216 everything works nice and fast.

Is there some way I can make this faster using stretchblt. Is there maybe a way I can use the DirectX StretchBlt call to send the image data to my CStatic Device Context? Is there maybe some way I can manipulate the byte array to change the size of the image and then use the regular bitblt call?

Any ideas on how to make this faster?

Thanks,
Greg

[miteshpandey]

Just some things you can give thought to.

I think this has to do with at what rate are you drawing the view (invalidating the view). You may be invalidating the view too soon while the window is being drawn for the previous invalidate command.

Perhaps you can use a timer to control when you are invalidating the window.

Or you can handle the incoming stream of data in a separate thread and post a message to the window to invalidate the view after certain amount of data arrives. This way your data can keep coming while the view is drawing itself.

You can also try using a memory DC. First blit into the memory DC then from the memory DC to the windows DC.

[revg75]

Hi,

thanks for the thoughts. I am actually using a multimedia timer to update the screen. My settings are this

timeSetEvent(100,250, (LPTIMERCALLBACK)&TimerProc, (DWORD)this, TIME_PERIODIC)

I am handling the streaming data in a worker thread as well.

I am also using the memdc class.

however I seem to get the same slow results.

I wish there was a faster way....

Thanks

[Oliver M.]

You can also try using a memory DC. First blit into the memory DC then from the memory DC to the windows DC.

Double buffering can be used to prevent flickering, but is slower in every case I used it. Maybe you can point out why/how this should speed up the display process?

[miteshpandey]

Double buffering can be used to prevent flickering, but is slower in every case I used it. Maybe you can point out why/how this should speed up the display process?

Yeah, you are right that double buffering can be used to avoid flickering but not to improve performance.

Just thought that the OP might be experiencing flickering and to remedy this he is looking for faster methods.

[aewarnick]

If you want speed, don't use Gdi at all, use OpenGL. In my tests I found that OpenGL is about 15 times faster than Gdi.

[diehardii]

This can be done in directshow/directx, but it is probably more trouble than it is worth. You might want to try resizing using different algorithms rather than stretchblt. For instance, the intel IPP has very fast resizing algorithms. If you prefer free (and who doesn't) you can take a look at the ffdshow code at sourceforge. That project has assembly versions of resizing algorithms that are highly efficient. Good luck.

~Steve

[aewarnick]

How could they be more efficient if they are not hardware accelerated?

[diehardii]

Hi aewarnick,

Well the efficiency will be dependent on your video card/ processor combo. The ipp and ffdshow algorithms besides being efficient, also take advantage of the mmx/sse2 instructions on the p3/p4. This helps if you are say on a laptop where your graphics card is not powerful. Also, if you are rendering in video memory, then that buffer is essentially lost to you unless you do the very expensive step of reading from video memory. However, if you are running the latest generation of graphics card, then I would agree with you that opengl/directx would be faster.

~Steve

P.S. To the OP, have you tried picking the lowest quality level for resizing in stretchblt?

[aewarnick]

I take it that the mmx advantage is only for intel processors?

[Alamar]

MMX is available on newer AMD processors as well.

As for effienciency, stretchblt wasn't made to be fast, as it wasn't intended to be called constantly. Ways other functions could be more efficient regardless of CPU specific additions/instructions include code and design improvements, as well as filtering issues (stretch something in MS paint compared to a filtered/aliased image editor - big difference in end result).

As for using hardware, whether it be through OpenGL or DirectX, that's not an insignificant amount of work/learning for something this trivial, but you can find tutorials and public source for this all over, including www.gamedev.net.

-Alamar

[greekgoddj]

P.S. To the OP, have you tried picking the lowest quality level for resizing in stretchblt?

How does one pick the quality of the stretchcliting? I am having a similar issue where must stretch blt a bitmap very often..on computers with decent graphics cards its not a problem....but on some PCs its soo slow that it puts the computer out of use while this stretchbliting is running.. I considered IPP but can the IPP technique be faster than the actual hardware/graphics cards implementation?

Aristotel

[diehardii]

Hi, setstretchbltmode will give you more options in gdi. In gdi+ there are even more options. I'm not sure, but gdi+ may use more of the hardware capabilities. My impression is that gdi+ is not a just a thin wrapper for gdi. Here is a link

http://msdn.microsoft.com/library/de...highdpiapp.asp

~Steve

[aewarnick]

Just remember Gdi+ does not work at all on win95.

[diehardii]

While that may be true, many programmers are no longer constrained to develop on those platforms . If you don't have those constraints, gdi+ is a bit easier.

~Steve