Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 238
  • Last Modified:

Most efficient display method

I have an client server app in which the server receives raw RGB video frames (384 x 288). It then passes a pointer to this frame to the client via WM_COPYDATA that now displays the frame.

At this stage I use DrawDibDraw to display the frames received. However when the video rate reaches about 100 frames per sec the display of the video consumes about 50% of the available cpu resources (Intel PIV 2.4 GHz on Win2000 prof).

Are there more efficient ways of displaying these RGB frames that would be less cpu processor intensive ? If possible please give some examples, or links to examples.

  • 2
1 Solution
199 frames per second is faster than the human eye can percieve and faster than the vertical refresh rate.  In other words, some of the frames are being displayed and not ever seen!  So one solution would be to simply drop frames once you reach about 30 FPS.

However, that is not the question you asked.  Are you certain that it is the rendering of data to the screen that is soaking up the CPU cycles?  The WM_COPYDATA is not particularly efficient and could be part of the problem.  You might consider opening a NamedPipe or other high-speed IPC mechanism.

-- Dan
ODAuthor Commented:

I investigated the NamedPipe/Socket/Mailslot options. The problem there is that I then have to transfer the whole frame (384 x 288 x 3 = 331kbyte per frame) from the server to the client. At 100fps that translates to some hefty data transfers, which after all my tests consumed even more cpu power than the WM_COPYDATA method.
The advantage of WM_COPYDATA is that I only need to "transfer" a pointer to the data/frames in the server and not pass the actual data itself.

Anyway, I am reasonably sure that it is the actual display that is eating away at the processor.

WM_COPYDATA has to copy the data from one process's address space to that of another.  That can be time-consuming, though perhaps not much more so than other IPC mechanisms.

>> I am reasonably sure that it is the actual display...

In your position,. I'd do whatever I could to be more than "reasonably sure"  I know that in the past, I have spent many hours "fixing" the wrong thing.  That is not only wasted time, it can introduce bugs into perfectly functional code!  

So now I ALWAYS allocate debugging time right at the start to being 100% certain where the problem lies.  In this case, it would probably take all of 20 minutes to run some tests where you timed the output-without-transport and timed the transport-without-output and compared the results to the output-and-transport.

-- Dan
No comment has been added lately, so it's time to clean up this TA. I will
leave a recommendation in the Cleanup topic area that this question is:

Answered: Points to DanRollins: Grade A

Please leave any comments here within the next seven days.

Experts: Silence means you don't care. Grading recommendations are made in light
of the posted grading guidlines (http://www.experts-exchange.com/help.jsp#hi73).


-bcl (bcladd)
EE Cleanup Volunteer

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now