Comments on: StretchBlt – Picture Stretching http://www.saqib-ansari.com/2008/04/stretchblt-picture-stretching.html Dream came true Tue, 06 Jul 2010 16:54:02 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Ariese http://www.saqib-ansari.com/2008/04/stretchblt-picture-stretching.html/comment-page-1#comment-9 Ariese Sun, 07 Sep 2008 05:47:30 +0000 http://www.saqib-ansari.com/?p=3#comment-9 The ability to draw an image on the screen that is a different size than the original source image is incredibly easy with Win32's GDI StretchBlt function and its variants. However, using StretchBlt with large images, especially with a large amount of stretch, is very slow. Also, shrinking images with StretchBlt often produces poor image quality. This article provides some simple techniques to get around the performance and image quality limitations of StretchBlt. The most aggravating effect caused by the poor performance of StretchBlt is to make scrolling very slow. If you call StretchBlt to draw an image each time the scroll bars are moved, you may be in for a long wait. A simple solution is to only call StretchBlt when the size of the image actually needs to change. Instead of stretching each time the image is drawn to the screen, only stretch it when necessary and rely on BitBlt (which is much faster) for the majority of your drawing. The downside of this approach means storing a copy of the stretched image in memory as well as the original source image. Considering the ever-present need for speed and these times of cheap memory modules, making a copy seems very reasonable. The ability to draw an image on the screen that is a different size than the original source image is incredibly easy with Win32′s GDI StretchBlt function and its variants. However, using StretchBlt with large images, especially with a large amount of stretch, is very slow. Also, shrinking images with StretchBlt often produces poor image quality. This article provides some simple techniques to get around the performance and image quality limitations of StretchBlt.

The most aggravating effect caused by the poor performance of StretchBlt is to make scrolling very slow. If you call StretchBlt to draw an image each time the scroll bars are moved, you may be in for a long wait. A simple solution is to only call StretchBlt when the size of the image actually needs to change. Instead of stretching each time the image is drawn to the screen, only stretch it when necessary and rely on BitBlt (which is much faster) for the majority of your drawing. The downside of this approach means storing a copy of the stretched image in memory as well as the original source image. Considering the ever-present need for speed and these times of cheap memory modules, making a copy seems very reasonable.

]]>