OD
asked on
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.
Cheers
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.
Cheers
ASKER
Dan
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.
OD
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.
OD
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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 (https://www.experts-exchange.com/help.jsp#hi73).
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
-bcl (bcladd)
EE Cleanup Volunteer
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 (https://www.experts-exchange.com/help.jsp#hi73).
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
-bcl (bcladd)
EE Cleanup Volunteer
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