Archived

This topic is now archived and is closed to further replies.

Triple-buffering in GDI using DIBs... eep.

This topic is 5651 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a set of three device contexts. The first is a context for my original bitmap, which I want to get out of a buffer (from a video camera that does frame captures) using StretchDIBits. This is then transferred via StretchBlt to the middle buffer where I add an overlay (to avoid stretching the overlay lines, while avoiding screen flickers), then that whole mess is copied via StretchBlt over to the primary device context (screen). This works terrific when I select a bitmap object into my first buffer then run it through, but for some reason my StretchDIBits isn''t cooperating in the least.
result = StretchDIBits( bitmapDC.m_hDC, 0, 0,
  rect.Width(), rect.Height(), 0, 0,
  m_viewBmi->bmiHeader.biWidth,
  0 - m_viewBmi->bmiHeader.biHeight,
  m_buffer.pBuffer,( BITMAPINFO* )m_viewBmi,
  DIB_RGB_COLORS, SRCCOPY );
 
I''m using VC7, and it doesn''t even have StretchDIBits in the index. I''ve checked msdn and Codeguru and it''s not helping much. Anyone worked with this stuff? I tried cutting it down to
result = StretchDIBits( pDC->m_hDC, 0, 0, 
  rect.Width(),	rect.Height(), 0, 0,
  m_viewBmi->bmiHeader.biWidth, 
  0 - m_viewBmi->bmiHeader.biHeight,
  m_buffer.pBuffer, ( BITMAPINFO* )m_viewBmi,
  DIB_RGB_COLORS, SRCCOPY );
 
but that gives me a result = 0, which is even worse than attempting on the bitmap dc. Thanks -fel

Share this post


Link to post
Share on other sites
just a shot in the dark, have you tried using a positive height for the source height?

result = StretchDIBits( bitmapDC.m_hDC, 0, 0, rect.Width(), rect.Height(), 0, 0, m_viewBmi->bmiHeader.biWidth,

>>> m_viewBmi->bmiHeader.biHeight, m_buffer.pBuffer,

( BITMAPINFO* )
m_viewBmi, DIB_RGB_COLORS, SRCCOPY );

Share this post


Link to post
Share on other sites
Have you tried checking the error code using GetLastError()? That will tell you when you went wrong.


Documentation of StretchDIBits from my MSDN

//---------------

Platform SDK: Windows GDI StretchDIBits The StretchDIBits function
copies the color data for a rectangle of pixels in a DIB to the
specified destination rectangle. If the destination rectangle is
larger than the source rectangle, this function stretches the rows
and columns of color data to fit the destination rectangle. If the
destination rectangle is smaller than the source rectangle, this
function compresses the rows and columns by using the specified
raster operation.

Windows 98 and Windows 2000: StretchDIBits has been extended to allow
a JPEG or PNG image to be passed as the source image.

int StretchDIBits( HDC hdc, // handle to DC int XDest, // x-coord of
destination upper-left corner int YDest, // y-coord of destination
upper-left corner int nDestWidth, // width of destination rectangle
int nDestHeight, // height of destination rectangle int XSrc, //
x-coord of source upper-left corner int YSrc, // y-coord of source
upper-left corner int nSrcWidth, // width of source rectangle int
nSrcHeight, // height of source rectangle CONST VOID *lpBits, //
bitmap bits CONST BITMAPINFO *lpBitsInfo, // bitmap data UINT iUsage,
// usage options DWORD dwRop // raster operation code ); Parameters
hdc

[in] Handle to the destination device context. XDest

[in] Specifies the x-coordinate, in logical units, of the upper-left
corner of the destination rectangle. YDest

[in] Specifies the y-coordinate, in logical units, of the upper-left
corner of the destination rectangle. nDestWidth

[in] Specifies the width, in logical units, of the destination
rectangle. nDestHeight

[in] Specifies the height, in logical units, of the destination
rectangle. XSrc

[in] Specifies the x-coordinate, in pixels, of the source rectangle
in the DIB. YSrc

[in] Specifies the y-coordinate, in pixels, of the source rectangle
in the DIB. nSrcWidth

[in] Specifies the width, in pixels, of the source rectangle in the
DIB. nSrcHeight

[in] Specifies the height, in pixels, of the source rectangle in the
DIB. lpBits

[in] Pointer to the DIB bits, which are stored as an array of bytes.
For more information, see the Remarks section. lpBitsInfo

[in] Pointer to a BITMAPINFO structure that contains information
about the DIB. iUsage

[in] Specifies whether the bmiColors member of the BITMAPINFO
structure was provided and, if so, whether bmiColors contains
explicit red, green, blue (RGB) values or indexes. The iUsage
parameter must be one of the following values. Value Meaning
DIB_PAL_COLORS The array contains 16-bit indexes into the
logical palette of the source device context. DIB_RGB_COLORS
The color table contains literal RGB values.

For more information, see the Remarks section.

dwRop

[in] Specifies how the source pixels, the destination device
context''s current brush, and the destination pixels are to be
combined to form the new image. For more information, see the
following Remarks section. Return Values If the function
succeeds, the return value is the number of scan lines copied.

If the function fails, the return value is GDI_ERROR.

Windows NT/ 2000: To get extended error information, call
GetLastError.

Windows 98/Windows 2000: If the driver cannot support the JPEG or PNG
file image passed to StretchDIBits, the function will fail and return
GDI_ERROR. If failure does occur, the application must fall back on
its own JPEG or PNG support to decompress the image into a bitmap,
and then pass the bitmap to StretchDIBits.

Remarks The origin of a bottom-up DIB is the bottom-left corner; the
origin of a top-down DIB is the upper-left corner.

StretchDIBits creates a mirror image of a bitmap if the signs of the
nSrcWidth and nDestWidth parameters, or if the nSrcHeight and
nDestHeight parameters differ. If nSrcWidth and nDestWidth have
different signs, the function creates a mirror image of the bitmap
along the x-axis. If nSrcHeight and nDestHeight have different signs,
the function creates a mirror image of the bitmap along the y-axis.

Windows 98/Windows 2000: This function allows a JPEG or PNG image to
be passed as the source image. How each parameter is used remains the
same, except :

If the biCompression member of BITMAPINFOHEADER is BI_JPEG or BI_PNG,
lpBits points to a buffer containing a JPEG or PNG image,
respectively. The BITMAPINFOHEADER''s biSizeImage member specifies the
size of the buffer. The iUsage parameter must be set to
DIB_RGB_COLORS. The dwRop parameter must be set to SRCCOPY. To
ensure proper metafile spooling while printing, applications must
call the CHECKJPEGFORMAT or CHECKPNGFORMAT escape to verify that the
printer recognizes the JPEG or PNG image, respectively, before
calling StretchDIBits. ICM: Color management is performed. The color
profile of the current device context is used as the source color
space profile and the sRGB space is used.

Requirements Windows NT/2000: Requires Windows NT 3.1 or later.
Windows 95/98: Requires Windows 95 or later. Header: Declared in
Wingdi.h; include Windows.h. Library: Use Gdi32.lib.

See Also Bitmaps Overview, Bitmap Functions, SetMapMode,
SetStretchBltMode, BITMAPINFO

Built on Wednesday, July 12, 2000Requirements Windows NT/2000:
Requires Windows NT 3.1 or later. Windows 95/98: Requires Windows 95
or later. Header: Declared in Wingdi.h; include Windows.h. Library:
Use Gdi32.lib. See Also Bitmaps Overview, Bitmap Functions,
SetMapMode, SetStretchBltMode, BITMAPINFO

Share this post


Link to post
Share on other sites
Can you isolate the Stretch DIBs? eg test it without stretching.


A possible alternative idea would be to create a true overlay surface - of the correct size of the original bitmap, apply your graphic overlay onto that and then use the HW overlay''s stretch caps to resize as needed.

This might even look better in the end.

Although it''s probably more complexity than you want to deal with - not to mention - you must have HW that does overlays that can be stretched....

Share this post


Link to post
Share on other sites
Unfortunately I''m not going to have any hardware help, due to what this is being used for (which I can''t talk about, sorry).

I''m starting to think there''s something wrong with the camera format to buffer translation, so I''m going to go poke at that a while. Everything else looks kosher.

-fel

Share this post


Link to post
Share on other sites
Your device contexts by default will contain 1x1 monochrome pixel. Make sure you create compatible bitmap then select it into the dc. Then blit stuff into this dc. I have double buffered 2D view windows in my 3D editor that use this scheme and never had a problem except when the view window has zero width or height. Just throwing out some info.

Share this post


Link to post
Share on other sites
Yep, I have a set of pre-load bitmaps to initialize my device contexts. They work fine when I''m running through normal bitmaps, just the DIBs from the camera aren''t processing correctly. Unfortunately the api''s for the camera have truly awful documentation. It''s long and doesn''t cover pretty much any of the commands used in their example code... and the header files aren''t any more helpful.

-fel

Share this post


Link to post
Share on other sites