is GetDC() slow?
Author
For drawing text using DirectDraw, you need to get the screen dc, but is it slow to do this and then release it every frame?
I don't think calling it only once per frame would be too large of a cost. Remember that you must also call ReleaseDC for each GetDC call. The additional calls may cost you a frame or two. The best way to find out I guess would be to profile your renderer.
GetDC() effectively performs a Lock() on the surface so that the GDI functions can get a pointer to that memory.
You should never leave a surface locked for more than one frame (including implied locks such as the one in GetDC).
Modern graphics cards can perform things such as Blt()'s between video memory surfaces without using any CPU time at all - however if you lock any of the surfaces that the card is currently using, then (unless you use the donotwait flag) the lock uses CPU time while it waits for the graphics card has finished with the surface; then when you have the surface locked, until you unlock the surface, the graphics card can't use that surface. For this reason, locking the primary surface or back buffer is usually a bad thing for your performance.
What I'd actually advise is having one or more system memory surfaces to write your text to (these will be very fast to Lock), then Blt() those to the surface you require, e.g.:
TextSurface->GetDC( &dc )
WriteTextToDC( dc )
TextSurface->ReleaseDC();
Blt( from:TextSurface, to:PrimarySurface )
if possible, use more than one TextSurface's and double (or more) buffer them - this should further reduce the chance of stalling the graphics card or CPU.
You should never leave a surface locked for more than one frame (including implied locks such as the one in GetDC).
Modern graphics cards can perform things such as Blt()'s between video memory surfaces without using any CPU time at all - however if you lock any of the surfaces that the card is currently using, then (unless you use the donotwait flag) the lock uses CPU time while it waits for the graphics card has finished with the surface; then when you have the surface locked, until you unlock the surface, the graphics card can't use that surface. For this reason, locking the primary surface or back buffer is usually a bad thing for your performance.
What I'd actually advise is having one or more system memory surfaces to write your text to (these will be very fast to Lock), then Blt() those to the surface you require, e.g.:
TextSurface->GetDC( &dc )
WriteTextToDC( dc )
TextSurface->ReleaseDC();
Blt( from:TextSurface, to:PrimarySurface )
if possible, use more than one TextSurface's and double (or more) buffer them - this should further reduce the chance of stalling the graphics card or CPU.
Author
Sounds Good. But I would only have to blit the section that was affected by text right?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement