Android color formats (RGB565, ARGB8888)

getHolder().setFormat(PixelFormat.RGBA_888); Options options = new BitmapFactory.Options(); options.inDither=true; options.inScaled = true; options.inPreferredConfig = Bitmap.Config.ARGB_8888; options.inPurgeable=true; 

(Bitmat created using the options above)

Using the above code, I get the following results .........

  • Missing color bar on my tablet device
  • Noticeable color gamut on a test mobile phone (Samsung Galaxy Ace)

     getHolder().setFormat(PixelFormat.RGBA_888); Options options = new BitmapFactory.Options(); options.inDither=true; options.inScaled = true; options.inPreferredConfig = Bitmap.Config.ARGB_565; options.inPurgeable=true; 
  • The lack of a color bar on the tablet

  • Color Tracking on the Galaxy Ace
  • Same results as above

     getHolder().setFormat(PixelFormat.RGB_565); Options options = new BitmapFactory.Options(); options.inDither=true; options.inScaled = true; options.inPreferredConfig = Bitmap.Config.RGB_565; options.inPurgeable=true; 
  • Grouping colors on a tablet

  • color bar on SG Ace

     getHolder().setFormat(PixelFormat.RGB_565); Options options = new BitmapFactory.Options(); options.inDither=true; options.inScaled = true; options.inPreferredConfig = Bitmap.Config.ARGB_8888; options.inPurgeable=true; 
  • Grouping colors on a tablet

  • color scheme on SG Ace

So in conclusion, only part of PixelFormat.xxxx seems to matter. I understand that it is necessary to set the color format of the holder. This will affect everything drawn. (i.e. everyone will accept this format).

Can someone please explain what the purpose of the next line is?

options.inPreferredConfig = Bitmap.Config.xxxxxxx

This does not seem to affect the bitmap that was drawn.

Performance is of the utmost importance, so I may have to change the source png files so that they don't have gradients (i.e. draw them as RGB565 - is it advisable, or should I stick to 8888?) Or should sort the sort, out? (because, as you can see, I turned it on, but it doesn't seem to help).

Any ideas why the bandage is always present on the ace? Could this be a hardware limitation?

Thanks, all this is very confusing.

(PS I read the official guide, I always look at this before posting a question to SO, and also look at other related SO questions, but the official guide (as often happens) does not clear this for me, and I could not find the answers to other questions, so I apologize if he is already here).

+4
source share
2 answers
Format

565 is the default because it can be done faster and requires less processing power. As for your SG Ace, I believe that some time ago only certain versions of Android supported the color 8888.

In order not to use one of my background applications, I had to do the following:

1 - add background to the folder with the picture

2 - Create background_dithered.xml with the following contents:

 <?xml version="1.0" encoding="utf-8"?> <bitmap xmlns:android="http://schemas.android.com/apk/res/android" android:antialias="true" android:dither="true" android:src="@drawable/background" /> 

3 - in action:

 @Override public void onAttachedToWindow() { super.onAttachedToWindow(); getWindow().setFormat(PixelFormat.RGBA_8888); } 
+4
source

Can someone please explain what the purpose of the next line is?

options.inPreferredConfig = Bitmap.Config.xxxxxxx

This does not seem to affect the bitmap that was drawn.

Different Bitmap configurations will have different memory traces. RGB_565 is a 16-bit color format. ARGB_8888 is a 32-bit format.

No matter what configuration getHolder().setFormat(); you chose or how you draw it, the bitmap ARGB_8888 will be much larger (in memory) than the bitmap in the RGB_565 format.

+2
source

All Articles