🚀 go-pugleaf

Robert G. Hoover wrote:

>DrawDibDraw(HDRAWDIB hDD, HDC hDC, int left, int top...);
>SetDIBitsToDevice(HDC hDC, int left, int top...)
>StretchDIBitsToDevice(HDC hDC, int left, int top, int width, int height...)

Can't find that function. How about StretchDIBits ?

>Which of these are thread safe? DrawDibDraw only?

Why would any of those be "thread safe" ?  If you only ever use one
thread for display, then that should be "safe".

>Does DrawDibDraw write "directly" to video memory rather than regular memory?
<help>
If the DrawDib DC does not have an off-screen buffer specified,
specifying DDF_DONTDRAW causes the frame to be drawn to the screen
immediately. Subsequent calls to DrawDibDraw specifying DDF_UPDATE
fail.  </help>

> Is there a difference on these modern PCs?

Yes. Except for integrated video which shares memory.

>Which would be best used for video streaming? Are there other options?

Two threads, one for aquiring data, one for displaying it. Proper
buffering techniques can make it safe.
You might even go for three threads, with a data massager in the
middle.

Affinity mask. Set all your threads to one core so it becomes a
single-processor system as far as your app is concerned. (You said it
was faster on a single cpu.)

You might also play with thread priority settings.

>Please forgive my ignorance. I've been writing video streaming apps for nearly
>15 years. Apparently, I've been writing them wrong. ;)

So, what's really the problem?
Is it still slow?
Or are other issues cropping up?