Cheap pixel formats in series40

[roxenhag]

Hello,

I am having problems with the drawPixels method in DirectGraphics on my series40 emulator/phone (6800). The Nokia UI API Programmer's Guide states that all phones support the TYPE_BYTE_1_GRAY_VERTICAL pixel format but that doesn't seem to be true. I get IllegalArgumentException when using the test method createInvertedImage supplied in the document. It works fine on the series60 emulator though. Is there a list somewhere of what pixel formats (except the native one) that are supported in series40 phones?

My original problem is rendering pages of text with a reasonable speed that makes scrolling possible. Since the drawString method is slow and the drawImage method is fast (at least in comparison) I want to "pre-render" my text to an image and use the image when srolling. This is however very expensive and therefore I want to use a cheaper pixel format (1 bit) for storing the image but no cheaper formats than the native seem to be available.

Would really appreciate help on this.

[doctordwarf]

roxenhag
I use TYPE_USHORT_4444_ARGB format. It seem to be supported by all the Series 40 and Series 60 phones.

This is however very expensive and therefore I want to use a cheaper pixel format (1 bit) for storing the image but no cheaper formats than the native seem to be available.

If you actually use 2 colors only, you images will compress extremely well and I suppose, the final size in the JAR would be almost the same as for 1 bit pictures.
Check this (and of course post report here)

[dannyc4]

Why not creating your "character" images or short[] arrays using drawString and store them? I think 6x8 should be enough. That takes 96 bytes per character.

Since you need about 80 chars for the entire alphabet in upper and lower case, numbers and some special characters, it would cost 7680bytes of your heap size, which is acceptable. Furthermore it frees up your jar from any characterset data, though it limits you to system charactersets.

Try to use 8bit ascii for your text, thus combine 2 chars in a java type byte, char or short and extract them using bitshifting and masking. This saves memory usage a lot.

BTW, I don't think DrawString() takes that long... It's just about using it right. A lot of drawImages takes a lot of time as well. Do you have a need for horizontal scrolling and doesn't lcdui provide what you need by a change?