Los mapas de bits en ICS se cargan con formato de píxeles incorrecto
Encontré el siguiente problema. Cuando cualquier mapa de bits se carga desde recursos por una aplicación que se ejecuta en Ice Cream Sandwich, es probable que se procese incorrectamente como si se haya decodificado en el formato, que difiere del formato de ventana actual, sin aplicar dither. Sin embargo, tanto el formato de decodificación como el formato de ventana se han definido explícitamente:
BitmapFactory.Options opts = new BitmapFactory.Options(); opts.inPreferredConfig = Bitmap.Config.RGBA_8888;
y
- Cambiar el icono de desbordamiento en la barra de acción
- ¿Cómo puedo forzar la barra de acción a estar en la parte inferior de ICS?
- Android "No se encontró proveedor de contenido ni se revocó el permiso" con android 4
- ¿Cómo entrar en el modo de fastboot para las tabletas Allwinner A10 (ICS)?
- Android 4.0 / ICS - Icono de la aplicación en la barra de acciones no se puede hacer clic
getWindow().setFormat(PixelFormat.RGBA_8888); getWindow().addFlags(WindowManager.LayoutParams.FLAG_DITHER);
Aquí hay capturas de pantalla de la aplicación de prueba tomada de este artículo que se ejecuta en Emulator con ICS 4.0.3 (da los mismos resultados en HTC HD2):
RGBA_8888
ventana RGBA_8888
(32 bits), varios formatos de decodificación de mapa de bits:
RGB_565
de ventana RGB_565
(16 bits), varios formatos de decodificación de mapa de bits:
Se pueden notar varias cosas:
- Dithering bandera no se tiene en cuenta de vez en cuando;
- El formato de ventana predeterminado para ICS parece
RGB_565
; - El único gradiente de buena apariencia aparece con formato de ventana
RGBA_8888
y formato de decodificación de mapa de bitsRGBA_8888
.
Este problema también se ha informado en estas preguntas, pero todavía no se puede encontrar ninguna solución allí:
Problema de compatibilidad de degradado: ICS adopta por defecto menos colores que todas las versiones anteriores de Android
Awful calidad de imagen de fondo en Android
¿Cómo tratar todos estos formatos en ICS, para ser más preciso, cómo hacer mapas de bits de carga de ICS con formato RGBA_8888
y cómo configurar el formato de ventana a RGBA_8888
para que estos mapas de bits se muestren correctamente?
- ¿Cómo configuro el emulador de Android 4.0+ para que se comporte como una tableta?
- PACKAGE_ADDED BroadcastReceiver no funciona
- Fácil manera de ocultar la barra del sistema en Android ICS
- Visualización de elementos de menú en la barra de acciones de Android ICS
- SetHomeButtonEnabled en PreferenciaActividad y preferencia anidada
- ErrnoException: isConnected falló: EHOSTUNREACH (No hay ruta al host) al cambiar la red wifi usando ICS
- No se puede convertir de android.support.v4.app.Fragment a android.app.Fragment
- WebView loadDataWithBaseUrl - problema extraño en android 4.0.3
Definitivamente puedo asegurar que el formato de ventana predeterminada es RGB888. Esto fue hecho por defecto en Android 2.3, y no ha sido cambiado desde entonces. En este punto me gustaría considerar RGB565 ventanas obsoletas, ya que básicamente todos los dispositivos actuales tienen pantallas 32bpp.
Usted dice que también se está ejecutando esto en el HTC HD2, pero ya que no hay compilación oficial para que sería sospechoso de cualquier resultado que se llega allí.
Creo que el emulador todavía puede utilizar pantallas 16bpp, por lo que en esta área no confiaría en sus resultados para que coincida exactamente con lo que normalmente se verá en los dispositivos.
Esa aplicación de demostración es un poco extraño … tiene dos actividades que filtran la intención del lanzador, una destinada a 16bpp y otra a 32bpp. No estoy seguro de qué determina cuál es elegido cuando se inicia la aplicación.
Ejecutar la aplicación tal y como está en un dispositivo ICS (un Nexus S en ejecución 4.0.3) da como resultado que se elija la versión 16bpp. Si elimina la declaración de actividad 16bpp del manifiesto, no sorprende que lance la versión 32bpp en su lugar. Que me parece bien. La opción 'dither' no tiene efecto en 32bpp, pero eso es lo que se espera … el dithering solo entra en juego cuando la profundidad de la superficie de visualización es menor que la profundidad de la imagen.
En cuanto a las profundidades de la superficie de visualización, mi entendimiento es que la profundidad de la superficie de la ventana se utiliza por defecto a 16bpp, hasta Android 3.0 (Honeycomb) en que punto por defecto silenciosamente cambió a 32bpp. El valor predeterminado siempre se ha sobreescrito mediante Window.setFormat()
.
- Cómo detectar la utilización de datos en el entorno de Android
- ListSelector de Android todavía parcialmente visible cuando el elemento se desplaza hacia fuera