 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| BitBlt or GUI faster? |
|
 |
Gyannea Member since: 3/4/2003 From: Candia, USA |
|||
 Posted - 3/24/2003 8:40:03 PM |
||||
| Does anyone know whether it would be faster to write to a virtual window in memory (used for WM_PAINT messages) using a GUI function like Rectangle(blah, blah,...) and then copy it to the screen using BitBlt(), or just using the GUI function Rectangle() once more but with the screen device context? (I am hoping the BitBlt() function knows not to draw to a covered window.) I would think the BitBlt() would have less overhead than the GUI function. I tried just invalidating the region after drawing to the virtual window but sometimes updates came to late and it messed up the display (I am displaying audio data in real time). Brian Reinhold |
||||
|
||||
|
Skizz Banned Member since: 1/31/2003 From: United Kingdom |
|||
Posted - 3/25/2003 9:07:08 AM |
||||
| It depends a lot on the graphics hardware and how much overdraw there is in your rendering (by this, how many times on average a pixel is written to in one render pass). It will be quicker to draw to a memory DC than a video device DC since the bus speed is greater between CPU and RAM than between CPU and PCI/Video. But, you will need to send something over the PCI eventually, so it comes down to the overdraw amount. If you have very little overdraw then using the device DC would be quicker. Above a certain threshold it would be quicker to use a memory DC. What that threshold is is dependant on the system it's running on. Time it and see. Skizz P.S. It may be advantageous to use an memory DC since redraws that occur due to portions of the screen being revealed would be quicker (since the image already exists in memory). You will need to do your own dirty-rectangle system for the memory DC though. [edited by - Skizz on March 25, 2003 9:09:22 AM] |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 3/25/2003 10:28:36 AM |
||||
| for speed, try not using invalidate/paint as your main drawing method. instead, when the app needs to update a window DC area, try using GetDC and then update using it. this will save you the overhead of processing the window msg's that come from invalidate and paint. also try using an owner DC for your window class. |
||||
|
||||
|
Gyannea Member since: 3/4/2003 From: Candia, USA |
|||
|
Posted - 3/25/2003 1:49:58 PM |
||||
| I am not sure what an owner DC is. On the other hand, the way I handle WM_PAINT messages is to create a memory compatible bitmap and then use the info from the PAINT structure to BitBlt() from the memory window to the screen. Now when I want to draw on the screen (for example I display waveform audio being received from the soundcard at quite rapid intervals by drawing the background rectangle and then plotting the waveform on top of it with Polyline(). I draw this to the memory device. Now I have tried the 'InvalidateRect()' but that was too slow and missed updates. So instead I have (1) repeated the GUI draw functions on the screen or (2) simply BitBlt() the drawn region from the memory device to the screen. My guess was that (2) would be faster as long as it didn't cause any trouble. What does an "owner DC" do and what is it? Would this be a means of further lowering overhead? Maybe its better to use Direct Draw? At least that way I can set "interrupts" (get window messages) at certain stages of the sound buffer as it fills. I can't do that with the MM functions. Brian Reinhold |
||||
|
||||
|
Rob Loach Staff Member since: 12/2/2002 From: Toronto, Canada |
|||
|
Posted - 3/25/2003 2:17:52 PM |
||||
| DirectX 7 - Rob Loach Current Project: Upgrade to .NET and DirectX 9 Percent Complete: X% |
||||
|
||||
|
Gyannea Member since: 3/4/2003 From: Candia, USA |
|||
|
Posted - 3/26/2003 5:59:38 AM |
||||
| Rob, That's a convincing answer! Is Direct Sound that much better? (My big load is handling the sound, not the graphics.) I will need all the time I can get for DSP work and I would like the timing to be as accurate as possible. Brian Reinhold |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
