Windows provides a number of functions for drawing raster data. Some of these have restrictions (they can't handle rotated data); others are not implemented on all operating systems; and various of them don't work properly (or are very slow) depending on the display and printer drivers in question.
MicroGDS uses an algorithm which works optimally most of the time; but on certain computer configurations the Windows functions we call might work slowly, not draw properly, or even cause a crash. In order to avoid such problems we have provided the user with the means to influence the algorithm via settings on the Raster tab of the File>Preferences dialog.
MicroGDS uses the following algorithm when drawing raster photos...
if GDI+ enabled or required due to fading/transparency
if not a perspective view & enabled(PlgBlt)
use version of Graphics::DrawImage() which can rotate the image
else
do transformation in software
use a non-rotating version of Graphics::DrawImage()
endif
else
if not a perspective view
if (NT,2K,XP) & enabled(PlgBlt) try PlgBlt(), stop if returns success
if raster is unrotated
if enabled(StretchBlt) try StretchBlt(), stop if returns success
if enabled(StretchDIBits) try StretchDIBits(), stop if returns success
endif
endif
if nothing else has worked, use software blitter
endif
This algorithm is explained in a bit more detail below. If you are not interested in this level of detail, then just try the steps outlined in What to Try, below.
The windows function PlgBlt can draw raster data at any rotation (although not in perspective), but it has two serious problems: it is only available on Windows NT, 2000 and XP (not on Windows 95, 98 or Me); and praphic card and printer manufacturers frequently supply a very slow or buggy implementation of this function. So...
GDI+ provides a function with similar capabilities to PlgBlt, the use of which is also controlled by this option (if the GDI+ check box is checked).
The windows function StretchBlt can draw raster data unrotated, or mirrored in X, Y or both. Printer manufacturers sometimes supply a slow or buggy implmentation of this functions, however, so...
The windows function StretchDIBits has the same capabilities as StretchBlt, but is slower for our purposes (it involves reading the data out of one bitmap into a temporary buffer, and writing it to the screen or a printer from that temporary buffer). MicroGDS will therefore prefer to use StretchBlt unless you've disabled it. So...
GDI+ is a new graphics library provided by Microsoft, being the successor to the old GDI (Graphics Device Interface). It seems to work better (in terms of producing complete output) on at least some printers, and also provides support for alpha channels. It may be marginally slower. It is included or can be installed on all versions of Windows we currently support. It is used elsewhere in MicroGDS when required for phase fading, new brushes, etc.
A number of options are available in terms of how we present raster data to this library. We choose between one similar to PlgBlt and one which cannot rotate the image (i.e. we do all the transforming of the data), based on the setting of the PlgBlt optimization.
If this optimization is checked, then neither StretchBlt nor StretchDIBits will ever be used, so optimizations 1 and 3 are ignored.
If there are no windows calls which are
Then we use some pixel-by-pixel copying code of our own. Given a high quality implementation of the graphics card and printer drivers, this should be much slower. Regrettably, these drivers often seem to be so poorly written (especially for the PlgBlt function) that our pixel-by-pixel code is much faster.
Even this doesn't always work: it needs to use SRCAND and SRCPAINT raster operations with the BitBlt function, and some drivers can't cope.
In general, there's no need to experiment with all combinations of the optimization settings; but try:
It's also worth looking to see whether there's an updated driver for your printer or graphics card available from the manufacturer or from the Microsoft Windows Update web site.