DIB vs. DIB
Norman Diamond
First, a refresher of one obscurity observed last month. Hidden at the
bottom of an oddly chosen MSDN page is this gem:
http://msdn2.microsoft.com/en-us/library/ms532337.aspx
> The scan lines are DWORD aligned, except for RLE-compressed bitmaps. They
> must be padded for scan line widths, in bytes, that are not evenly
> divisible by four, except for RLE compressed bitmaps. For example, a 10-
> by 10-pixel 24-bpp bitmap will have two padding bytes at the end of each
> scan line.
As observed last month, that information is missing from these pages:
http://msdn2.microsoft.com/en-us/library/ms532354.aspx
http://msdn2.microsoft.com/en-us/library/ms532317.aspx
These two pages describe the general format of DIBs instead of just the
headers, which makes them too obvious a place to look.
Well, this month's observation is better:
http://msdn2.microsoft.com/en-us/library/ms532305.aspx
> lpvBits
> [in] Pointer to an array of color data used to set the colors in a
> rectangle of pixels. Each scan line in the rectangle must be word aligned
> (scan lines that are not word aligned must be padded with zeros). If this
> parameter is NULL, the contents of the new bitmap is undefined.
So I can't call CreateBitmap before calling StretchDIBits. StretchDIBits
needs scanlines that are DWORD aligned. In some cases that might pad each
scanline by 2 or 3 bytes. But CreateBitmap needs scanlines that are word
aligned. The padding is only allowed to be 0 or 1 byte. If the amount of
padding is 2 or 3 bytes then we get ship-it awards (skews me).
Is there any way to create a device independent bitmap that can be
stretched?
Or am I reading the wrong MSDN page? CreateDIBitmap creates device
dependent bitmaps, right? CreateCompatibleBitmap creates device dependent
bitmaps, right? CreateBitmap intentionally creates a completely
incompatible bitmap? Any way to create one compatible with device
independent bitmaps?
Chris Becke
properly formatted BITMAPINFO structure, plus a array of bytes describing
the pixels. This array of bytes is bottom up and DWORD aligned.
A HBITMAP is a handle to a device dependent bitmap. Its device dependent,
because the video device driver manages the bits of the bitmap - which is
why all you get is a handle to the DDB.
CreateBitmap and CreateDIBitmap therefore BOTH create DDBs. As does
CreateCompatibleBitmap and anything that returns an HBITMAP.
To create a DIB on the other hand, all you do is initialize a BITMAPINFO +
allocate a byte array. You dont make any GDI calls at all to create a DIB.
CreateBitmap really seems to be a holdover utility function from Win16 that
sticks around because some people are too lazy to change to
CreateCompatibleBitmap/CreateDIBitmap. It has wierd semantics: WORD padding,
and a lack of DC parameter means GDI has to do "interesting" (Read CPU
consuming) work when you finally try select it into a DC. But it is useful
to quickly create monochrome mask bitmaps.
To confuse the DDB / DIB issue just a bit there is a third type of bitmap: A
DIBSection. A DIBSection is a hybrid bitmap that is both a DDB and a DIB:
CreateDIBSection creates a bitmap that both has an HBITMAP - indicating it
can be used like a DDB - selected into DCs etc, as well as a usermode
accessible BITMAPINFO + pvBits.
(DIBSections are also the *only* way to get GDIs AlphaBlend function to
actually apply alpha effects regardless of the primary display's bitdepth.)
"Norman Diamond" <ndia...@community.nospam> wrote in message
news:uC4CYiDI...@TK2MSFTNGP04.phx.gbl...
Grzegorz Wróbel
> Ok. Some terminology. A DIB is a Device Independent Bitmap. It consists of a
> properly formatted BITMAPINFO structure, plus a array of bytes describing
> the pixels. This array of bytes is bottom up and DWORD aligned.
>
The last sentence is wrong in that sense the bitmap bits might be as
well bottom-up as top-down. The sign of the biHeight field of the
BITMAPINFOHEADER determines this.
--
Grzegorz Wróbel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
Grzegorz Wróbel
>
> Well, this month's observation is better:
> http://msdn2.microsoft.com/en-us/library/ms532305.aspx
>> lpvBits
>> [in] Pointer to an array of color data used to set the colors in a
>> rectangle of pixels. Each scan line in the rectangle must be word aligned
>> (scan lines that are not word aligned must be padded with zeros). If this
>> parameter is NULL, the contents of the new bitmap is undefined.
>
> So I can't call CreateBitmap before calling StretchDIBits.
> StretchDIBits needs scanlines that are DWORD aligned. In some cases
> that might pad each scanline by 2 or 3 bytes. But CreateBitmap needs
> scanlines that are word aligned.
The word "word" in here means word of the machine (and since this entry
is quite old it assumed 32bit Windows). So read that "word" as DWORD.
Norman Diamond
can't imagine why I keep forgetting which DIBs are DIBs and which DIBs are
DDBs, when the APIs are named so clearly. Anyway, I fixed this
bugliographic bug.
Now, CreateDIBSection ALSO returns an HBITMAP. So your statement "A HBITMAP
is a handle to a device dependent bitmap" is as confused as me...
"Chris Becke" <chris...@gmail.com> wrote in message
news:e$lHNnFII...@TK2MSFTNGP04.phx.gbl...
Norman Diamond
news:fgph3o$pds$1...@atlantis.news.tpi.pl...
Then in x64 I have to make it a LARGE_INTEGER?
Ivan Brugiolo [MSFT]
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Norman Diamond" <ndia...@community.nospam> wrote in message
news:OXlhaaGI...@TK2MSFTNGP02.phx.gbl...
Grzegorz Wróbel
I wrote that this MSDN entry is quite old, when it was created that
problem (64bit Windows) didn't existed for the person writing it.
It also is possible that in very early specifications of bmp file format
(before version 3.0) scan lines were indeed WORD aligned. This is just
speculation as I've never seen .bmp format specification prior to
version 3.0. However in early times this format was strictly suited to
existing hardware. One remnant of that times is biPlanes field of
BITMAPINFOHEADER structure.
Mark Salsbery [MVP]
> I've corrected my code to call CreateDIBSection instead of CreateBitmap.
> I can't imagine why I keep forgetting which DIBs are DIBs and which DIBs
> are DDBs, when the APIs are named so clearly. Anyway, I fixed this
> bugliographic bug.
>
> Now, CreateDIBSection ALSO returns an HBITMAP. So your statement "A
> HBITMAP is a handle to a device dependent bitmap" is as confused as me...
>
A DIBSection is unique, because although it's a DIB, it has a HBITMAP so it
can be used like a DDB in GDI functions. That can be confusing :)
Mark
--
Mark Salsbery
Microsoft MVP - Visual C++
Norman Diamond
> One remnant of that times is biPlanes field of BITMAPINFOHEADER structure.
I saw some biPlanes in the Science Museum in London. If I recall correctly,
they didn't have windows.
OK, thank you everyone. I got this one fixed, for now.
Ron Francis
between DIBs and DDBs.
One thing stuck in my throat for a while...
Is CreateDIBitmap a misnomer??
I read it as CreateDeviceIndependentBitmap
Should it not be more appropriately named CreateDDBitmap or am I missing
something?
Regards,
Ron Francis
www.RonaldFrancis.com
"Chris Becke" <chris...@gmail.com> wrote in message
news:e$lHNnFII...@TK2MSFTNGP04.phx.gbl...
Mark Salsbery [MVP]
news:eOjq23XI...@TK2MSFTNGP06.phx.gbl...
>I got incredibly confused when I first started looking at the difference
>between DIBs and DDBs.
> One thing stuck in my throat for a while...
> Is CreateDIBitmap a misnomer??
> I read it as CreateDeviceIndependentBitmap
> Should it not be more appropriately named CreateDDBitmap or am I missing
I agree. I've always thought it was misnamed :)
Mark
--
Mark Salsbery
Microsoft MVP - Visual C++
> something?
Chris Becke
>between DIBs and DDBs.
> One thing stuck in my throat for a while...
> Is CreateDIBitmap a misnomer??
> I read it as CreateDeviceIndependentBitmap
> Should it not be more appropriately named CreateDDBitmap or am I missing
> something?
There is already a CreateDDBitmap. Three actually - CreateBitmap,
CreateBitmapIndirect and CreateCompatibleBitmap.
CreateDIBitmap might have been better named CreateBitmapEx or
CreateBitmapFromDIB...
There is a little precedent for the *source* to influence the function name:
See StretchBlt vs StretchDIBits.
Ron Francis
> CreateBitmapIndirect and CreateCompatibleBitmap.
>
> CreateDIBitmap might have been better named CreateBitmapEx or
> CreateBitmapFromDIB...
Point taken.
I would prefer CreateBitmapFromDIB or CreateDDBFromDIB.
My basic problem is that the word 'bitmap' has almost become synonymous with
DDB when it shouldn't be.
I can understand it though because DIBs didn't exist when the first bitmap
functions were defined.
> There is a little precedent for the *source* to influence the function
> name: See StretchBlt vs StretchDIBits.
Also SetDIBits is a good example where the source is a DIB.
But look at GetDIBits where the source is a DDB?
SetDDBitsFromDIB and GetDIBitsFromDDB (or even SetDIBitsFromDDB) may have
been more appropriate.
Cheers.
Regards,
Ron Francis
www.RonaldFrancis.com