From: "Joe C. Hecht" Subject: Re: max Size of a Bitmap ? Date: 21 Jul 1999 00:00:00 GMT Message-ID: <37963E56.11A3@gte.net> Content-Transfer-Encoding: 7bit References: <7n58cr$kp11@forums.borland.com> Content-Type: text/plain; charset=us-ascii Organization: Offshore Technology Mime-Version: 1.0 Reply-To: joehecht@gte.net Newsgroups: borland.public.delphi.objectpascal Note: Its not a driver problem. The driver simply asks Windows for some memory for the larger bitmap, and things can break down from there. Due to limitations in Windows in its interaction with drivers, there are limits, but these limits are not cast in stone, and vary with the Windows version, the currect resources in use, the resolution of the display, the color depth, and the different ways windows and drivers interact. Printer drivers punt stuff back and forth with both the GDI and the display driver, and the GDI also punts stuff back and forth between the display driver and the printer driver. All things considered, you can only be assured (unless resources are exhusted) that the maximum safe size of a bitmap (DDB) is the screen size. The maximum size of a portion a DIB that can be safely blitted is the lesser of a) The screen size. b) the memory consumption of a screen load. ie: If the display is 8 bit, and the DIB is 24 bit, then you would what to limit your blts to chunks that are no larger than 1/3 the memory consumption of the screen (since the 24 bit DIB uses 3 times the amount of memory of the screen. You can go larger, but you do risk failure on some machine configurations. You can have a DIB that is for all practical purposes, almost unlimited in size. Personally, I would shy away from making dibs larger than 64k per scanline. So, to make a larger bitmap, the pros use an underlying DIB, and blt smaller sections back and forth to a DDB. This is why, on your better graphics packages, when viewing refreshes on a slower machine, you will often notice the bitmaps refreshing in "bands". Further, as you can see, Windows, the GDI, the video driver, and the printer driver all work together, so any failure along the way can affect everything else, so you will want to follow the same rules when printing a bitmap. Finally, if printing the bitmap, you will want to use a DIB and the Windoes API function StretchDIBits (even if no stretch is desired). Methods like the VCL StrethDraw() send a bitmap based on the screen to the printer, and thats an illegal operation under Windows. NT is much better at detecting this internally, but under 16 bit, StretchDraw to a printer will *generally* only work if the driver has provided code to workaround the illegal operation. Hope the explanition helped! Joe -- Joe C. Hecht http://home1.gte.net/joehecht/index.htm