Hi, You can also try by disabling the dithering on your 565 Canvas. Also remember that physical devices use screen with a 16 bits (565) precision or less. The "bad" blending you see on your computer screen is not, or almost not, visible on an actual device.
On Sat, Apr 5, 2008 at 11:41 AM, hanni <[EMAIL PROTECTED]> wrote: > > Wow, a breakthrough! > > I read in another post that Android's framebuffer uses the RGB_565 > color mode. So I tried creating a ARGB_8888 Bitmap and did all of my > rendering to that Bitmap. After I was done I copied the Bitmap to the > Canvas that I get from the onDraw()-method. This resulted in all semi- > transparent images looking MUCH better. Unfortunately this means > slower GUI updating, since I have to draw a full 320x460 (skipping the > top bar) image to the screen, after each render. > > From this I draw the conclusions: > > * If you draw images into an ARGB_8888 Bitmap, all alpha blendings are > done in 8 bit precision. Then you can draw the resulting image to the > Canvas provided by the onDraw()-method, and it will be converted to > RGB_565 > > * When drawing an image to the Canvas provided by the onDraw()-method, > the result is immediately converted to RGB_565 format. This means that > the next image, drawn on top, actually does its blending to a > background that is already in the RGB_565 format and the result looks > horrible. > > I have the following request to the developers of Android: > > Is there ANY possibility that the conversion to RGB_565 16-bit > graphics can be done AFTER all the rendering is finished? Perhaps at > the same time as the double buffer swapping takes place, or such? If > it doesn't mean a big performance hit, of course. > > Best Regards, > Daniel > > > > On 5 Apr, 19:05, hanni <[EMAIL PROTECTED]> wrote: > > Oh, I just noticed that if I try to do it the other way, that is, > > extract the pixels form the image and applying my own blending > > algorithm, another problem arises. There seems to be a bug in the > > Bitmap.getPixels() implementation, that causes any pixel that has a > > non 0xFF alpha, to automatically lose all its color and become black. > > So if the image has a pixel with a full red colour of 0xFFFF0000, it > > stays red, but if it is a semi-transparent red color such as > > 0x7FFF0000, it is returned as the color 0x7F000000, with both the > > getPixels() and the getPixel() methods. > > > > On 5 Apr, 18:02, hanni <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi, my application makes heavy use of semi-transparent .png's for > > > interesting graphics. I'm used to this, developing J2ME applications. > > > The alpha blending algorithm in Android, however, seems to be less > > > than adequate. Everything that is semi-transparent is restricted to > > > very few shades of color, and that goes for everything behind a semi- > > > transparent image aswell. > > > > > Does anyone know of a setting to enable a more accurate alpha blending > > > algortihm, even if it might require more CPU power? Currently, when I > > > really need something to look accurate, I would have to create an > > > array from that image and run my own blending algortim on it, > > > converting it back to an image afterwards.- Dölj citerad text - > > > > - Visa citerad text - > > > -- Romain Guy www.curious-creature.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
