> I also remember reading that rendering is faster if > everything is at the "default" depth.
Yes, but things are complicated by the fact that lower depth bitmaps take up more memory and hence caching and uncompressing them takes longer. My feeling (having done a lot of optimization of rotation and other routines) is that WinDrawBitmap() is very fast on all units--we don't need to worry about the time that WinDrawBitmap() takes to draw a bitmap. What can slow things down for bitmap images is rotation, but that doesn't depend on the default depth. (I don't know what depths rotate fastest. My feeling is that 8- and 16-bit depth images might rotate faster than 1-bit images, but memory caching may change that in favor of 1-bit images.) I don't think speed is an issue here. > Do we zip image records? I assume that an image which > is actually monochrome should at least compress well. Yes, but there is still a difference for a compressed image. Moreover, in the case of a multiimage that is in fact all b&w, dropping to 1-bit depth before conversion (as the parser, as modified by me, does now in cases where PIL is used) reduces the number of segments the image requires, no doubt sometimes to the point where there is no multiimage used, and this seems to increase rendering speed as well as decrease the file size. > > With a background color set, should we have b&w > > images show up as black&background or as black&white? > > We don't want black & dark grey (or white and light gray). Well, if the user sets his background to dark gray, all text will look bad, too. > So long as the drawn color has enough contrast from the > background, I'm not sure it normally matters. If anything, > it would be better to use the chosen background color, > (and maybe the chosen foreground color). But if picking > the colors requires more space or time (explicit palette?), > then it probably isn't worth it. Well, currently, a 1-bit image is drawn in black&background, while a color image is drawn with whatever background the original image had. This has the consequence that if some images in a document are 1-bit and some are, say, 8-bit, things will look badly inconsistent--some images will have a white background and some a colored one. While some of the inconsistency is due to my optimization--which more and more I think should be made optional--similar inconsistency would be introduced by the old method of dropping the depth to fit under 60K. > Do palm bitmaps support a transparent color, so that > "black" could just let the background shine through? Unfortunately, transparency handling is a nuisance, as it differs between different versions of the bitmap format, as well as differing between different OS versions. The ideal would be to check if the original image has a transparent color (gifs might) and if so, translate that to a Palm transparent color. That said, background colors are a nuisance to handle, and not all Palm apps handle them well anyway. :-) E.g., the Palm Launcher's handling of background color on my NX70 isn't perfect. Background colors are a bit of a hack. I like to have some support for it (I like--following a hint someone once posted--to set my background to dark green for reading at night), and so the current anti-aliased-font code supports it, but I don't think we should bend over backwards to support it. Alex _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
