Article ID: 111865 - View products that this article applies to.
This article was previously published under Q111865
3.00 3.10 WINDOWS kbprg kbbuglist
If the stretching factor is large, for example, when stretching from a very small to a large height, StretchDIBits() and StretchBlt() may return zero (0) and display nothing. The same bitmap with a smaller stretch is displayed correctly.
Most display drivers do not implement their own StretchBlt() or StretchDIBits() so GDI must simulate these calls. Part of the GDI simulation involves allocating temporary work buffers, which are limited to 64K. If the size of the work buffer is calculated to be greater than 64K, then the height of the source and destination rectangles are halved until they are less than 64K. The problem is that if GDI must continue to divide the height by two (2) to get a buffer less than 64K, the source or destination height could eventually reach one scan line. At this point, the call fails because it cannot break up a scan line into subunits.
StretchBlt() and StretchDIBits() are not designed to provide unlimited stretching. However, they may fail a bit more prematurely than their design limitation.
If StretchBlt() or StretchDIBits() fails on a large stretch, an application can divide up the source bitmap, stretch the pieces individually, and position them correctly once stretched. Another alternative is to do a smaller stretch. There is no formula to determine exactly what bitmaps will fail at what stretch size.
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.
To reproduce the problem, create a bitmap approximately 2048 pixels wide by 16 pixels high. Then, display the bitmap with the DIBVIEW sample from the Windows 3.1 SDK. Choose Stretch To Window from DIBVIEW's Options menu, so that the bitmap is stretched according to the size of the client window. When the height is more than about 200 pixels, the bitmap will not be displayed.