Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Usage of Created Device Contexts

Status
Not open for further replies.

TI994A

Programmer
Aug 12, 2001
3
AE
[ul][li]Is there a better way to do animation
or fast graphics manipulation besides
using BitBlt to & from created device
contexts?[/li]

[li]In terms of memory consumption, and in
addition to the selected bitmap size,
what sort of overheads do these created
device contexts take up?[/li]

[li]In terms of CPU resources and disk access
times, would it be practical to restore &
delete each device context after use, and
then re-create and re-select objects when
needed again, even if these DCs are in
continous use throughout the app? (eg:
when used for bitmap animation sequences
like those in animated GIFs)[/li][/ul]

Resource Conscious
 
I can only answer your first bullet with confidence, sorry. I'm pretty sure the next thing faster than BitBlt is to use DirectX or some use of an assembly language for graphics. Assembly languages are lower level, and therefore much faster than the C++ equivelant like API. I know most game manufacturers will use assembly for their larger graphics and 3D routines.

To attempt to answer the second bullet, a device context is merely a long integer that Windows assigns as the handle to a bitmap image stored in memory. To literally answer the question, a device context consumes usually 4 bytes :) I do know that a .bmp file consists of four sections:

1.) BITMAPFILEHEADER: This contains the bitmap file signature, the size of the bitmap and the offset to the array of bits that define the bitmap image.

2.) BITMAPINFOHEADER: This contains information such as the height and width of the bitmap and the number of colors used

3.) The color table

4.) The actual bits that define the bitmap image

Of these four sections, only the last three are required for a DIB in memory. Since the BITMAPFILEHEADER is only a small amount of information, I would guess that the bitmap consumes nearly the same amount of RAM as physical disk space, which would make loading from disk more attractive to the resource concious.

On the other hand, information in RAM travels at nearly the speed of light at lower temperatures, whereas reading info from disk is invariably and noticably slower.

I know I didn't answer your question directly, but that's because I don't believe there is a correct answer to your questions. It all depends on factors like how many bitmaps and how large, what are the capabilities of your typical user's system, and how much effort you're willing to put forth. Hopefully I've provided some information that will help you make an educated decision.

Good luck!

-Mike Difference between a madman and a genius:
A madman uses his genius destructively,
A genius uses his madness constructively.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top