For fast screen access and low memory usage I had hoped to be able to use DirectGraphics.drawPixels(byte,...TYPE_BYTE_1_GRAY).
For my purpose it would have been so much nicer than the standard Java MIDP solution, where I am forced to cache whole Image objects that use e.g. 16 bits per pixel instead of 1.
The documentation says the following about TYPE_BYTE_1_GRAY (read carefully):
"The scanlength and offset parameters for drawPixels and getPixels are given in the number of pixels, not as indices to the pixels array.
All implementations must support this pixel format."
In the 3410 SDK it works fine, but the Series 30 SDK uses indiecs to the pixel array instead of number of pixels in the offset argument, quite contrary to the documentation. To make it work with the Series 30 SDK I have to divide offset by 8.
The 7210 SDK does not support TYPE_BYTE_1_GRAY at all, also contrary to the documentation. Instead, it throws IllegalArgumentException for the exact same statements that work with the other SDKs -- and I have made 100% sure that all the other arguments are legal. If I try TYPE_USHORT_444_RGB, which is the native format, it works (but gives funny colors).
My question is this: Shall I assume that the actual phones work as the SDKs (with the bugs) and spend lots of time trying to work around these problems, or will the phones work according to the documentation?