Thanks for the answer Aaron, I've done something similar to PrinterDC for our company's printers. You can draw in a virtual page (bitmapwindow) and then print it. Sooo... the printer is 1bit, the pages are quite big so I can't affort 8 bit or similar. Despite that, working with 8 bit images is slower. The bug is interesting: for example I'm doing something like that:
BBBBBBBBBBBBBBBBB B TTT TTT B B B B TTT TTT B BBBBBBBBBBBBBBBBB This should mean: some nice graphic border "B", and text "T" inside. On all OS5 devices the bug makes this looks like: XXXXXXXXBBXXXXXX B TTX XXX X B B B TTT XXX X XXXXXXXXXXXXXXX Where "X" is corrupted part. The corruption is not identical on every run, but nearly the same as result. The picture I showed above is made by the normal window functions drawing in this offscreen window - WinDrawBitmap, WinDrawChars, WinDrawLine... > 1bpp really shouldn't be used on the UI front end. you should only > be using it off-screen, and, dont expect the API's to be fully > compatible with 1, 2 or 4bpp in the future. An year ago there was virtually nothing different than 1bit. How does Palm "forgot" this time and this devices? They still exists. I must support them. And I don't want to allocate 8 or 16 times more memory just because Palm don't like backward compatibility??! I don't like that. I'll move to 8 bit and will make a separate converting function when OS5 is detected but I still think this is either a big bug or stupid decision. "Aaron Ardiri" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > That was my question a couple of days ago. Nobody answered. Not > > only bitmaps are corrupted - text, lines, rectangles, everything. > > The funny part is that some things does not get corrupted, some > > does... I dunno why. I'm allocating large screens and they MUST > > be 1-bit. This is some OS5 bug, on older devices even on Tungsten/W > > with high-res and 16bit this does not show. The bug is in OS5.0, > > 5.1.2, 5.2 and 5.3. Dunno how to report this to Palm but it's > > important to be fixed... if anybody pay attention to this problem > > how about working in 1bpp manually - that is, allocate your own > buffers and do operations on them; then, copy to 8bpp or 16bpp which > can be properly displayed by the device. > > some units, for example the tapwave unit are rumored to only run > in 16bpp, regardless of what graphics mode you request. > > 1bpp really shouldn't be used on the UI front end. you should only > be using it off-screen, and, dont expect the API's to be fully > compatible with 1, 2 or 4bpp in the future. > > --- > Aaron Ardiri [EMAIL PROTECTED] > CEO - CTO +46 70 656 1143 > Mobile Wizardry http://www.mobilewizardry.com/ > > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
