This article has been archived. It is offered "as is" and will no longer be updated.
3.00 3.10WINDOWSkbprg kbbuglist
If the stretching factor is large, for example, when stretching from a verysmall 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() orStretchDIBits() so GDI must simulate these calls. Part of the GDIsimulation involves allocating temporary work buffers, which are limited to64K. 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 untilthey are less than 64K. The problem is that if GDI must continue to dividethe height by two (2) to get a buffer less than 64K, the source ordestination height could eventually reach one scan line. At this point, thecall 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 by16 pixels high. Then, display the bitmap with the DIBVIEW sample from theWindows 3.1 SDK. Choose Stretch To Window from DIBVIEW's Options menu, sothat 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 bedisplayed.