Dar forma, poco a poco, a lo que importa.

Pintar el fondo de blanco o guardar una imagen como PNG no la vuelve transparente automáticamente. La transparencia requiere un canal alfa independiente, que indica cuánto debe verse cada píxel.

Las imágenes estáticas de DINKI pasan por segmentación del sujeto y procesamiento de máscaras: se predice una máscara de transparencia del sujeto y se conservan los colores originales. Después se comprueban la transparencia y los bordes sobre fondos oscuro, verde lima y papel para evitar dañar detalles como la ropa blanca o los reflejos de los ojos.

Los recursos animados siguen otra vía: la imagen de color del vídeo y su máscara de transparencia se empaquetan juntas, y el reproductor las separa y combina según el formato acordado. Un reproductor corriente puede mostrar bloques de color o la máscara; cambiar el color de fondo no lo arregla.

El selector de abajo solo muestra un recurso transparente existente sobre distintos fondos. No sube ni vuelve a procesar tus fotos en el navegador.

Para limitar la memoria, la solución inicial restringía el número de vídeos reproducidos a la vez. Reducía la carga, pero dejaba inmóviles otras tarjetas visibles.

La lista usa ahora atlas de fotogramas transparentes generados a partir de los vídeos de movimiento: 18 fotogramas por vista previa y un presupuesto de caché de 32 MiB. Todas las tarjetas visibles se reproducen; se pausan al desplazar la lista y se detienen fuera de pantalla. Parece un GIF, pero es un atlas de fotogramas con canal alfa.

Al abrir un personaje o reproducir un movimiento completo se siguen usando recursos de vídeo. La lista ya no necesita mantener un decodificador por tarjeta, y los vídeos originales de producción no se sustituyen por vistas previas de baja resolución.

Se debe seguir respetando la preferencia del sistema para reducir el movimiento. La fluidez se mide en dispositivos reales con la misma carga; el método de implementación por sí solo no permite afirmar un porcentaje de mejora.

La conversión crea un momento importante y elimina la nota original. Si la ficha y el editor están vinculados a esa nota, al borrarla la página inferior pierde el contenido que debe mostrar.

La corrección mantiene en el editor una copia estable del borrador. Primero termina el guardado y después la vista superior recibe el resultado y cierra la conversión y la ficha mediante los avisos de cierre. Las entradas se conservan al cancelar o si falla el guardado.

Es más fiable que enviar dos órdenes de cierre desde cualquier lugar: cada nivel gestiona su propio estado de visualización y, al terminar correctamente, se vuelve a una lista que sigue siendo válida.

Los diálogos de confirmación centrados reutilizan el componente común de la app, con título, explicación y una acción clara, en vez de crear avisos distintos para cada página.

La respuesta de Apple indica que la transacción tiene un resultado. El servidor aún debe verificar el pedido y su titularidad e impedir que se acredite dos veces. Cambiar solo la cifra en pantalla separaría el saldo del registro real.

Esta actualización vuelve a conectar al cliente la actualización confirmada del monedero y la membresía, evitando que consultas anteriores sobrescriban acreditaciones más recientes. El proceso se muestra en el botón de compra; normalmente el usuario no necesita entender una acción de «sincronizar compras».

Los pedidos simulados y reales se contabilizan por separado. Restaurar un archivo tampoco puede modificar el saldo de compras. Si falla la red, las transacciones pendientes se conservan y se reintentan, sin pedir al usuario que vuelva a comprar para recibir lo que le corresponde.

Se han comprobado la acreditación, la membresía y la reapertura para el plan mensual y las compras de Sol en la tienda real. Los procesos completos de reembolso real y renovación siguen siendo verificaciones pendientes antes de la publicación.