Cada píxel en el iPad es un rectángulo de componentes rojo, verde y azul, por lo que uno podría pensar que la representación de fuente subpíxel sería una buena opción para el dispositivo.
Pero tenga en cuenta que este dispositivo se puede cambiar fácilmente de los modos vertical a horizontal, y se espera que las aplicaciones respondan a ese cambio. Esto implicaría que su mecanismo de fuente subpíxel también tendría que responder a ese cambio, y necesitaría dos descripciones de subpíxeles separadas para cada fuente.
Ahora imagina que los desarrolladores esperan poder escribir aplicaciones universales que se ejecutan en el panel y los teléfonos en una sola compra/descarga. Pero mira las diferentes configuraciones de píxeles en las distintas generaciones de teléfonos en la imagen a continuación. Cada uno de ellos, recuerda, necesitaría describir las fuentes de forma diferente en modo retrato y paisaje. Ahora tiene una explosión de descripciones de fuentes.
Ahora recuerde que estamos hablando de dispositivos portátiles en los que el recurso más preciado es la batería, y el procesamiento de fuentes subpíxel es más intensivo en términos de computación.
Supongo que esto no es muy diferente del proceso de pensamiento que condujo a Apple a evitar la representación de fuentes subpíxel a favor de esperar que la tecnología de visualización aumente la densidad de píxeles hasta el punto en que ya no sea necesaria (la retina mostrar en el iPhone 4 es el primer paso en esa dirección.)
Apostaría a que en una edición futura del iPad, tendremos una pantalla con densidad similar, y no importará tanto. Cualquier esfuerzo que invierta tratando de inventar un mecanismo de representación de fuentes subpíxel para su aplicación de iPad se obviará inmediatamente en ese punto, por lo que le recomendaría que no siga por ese camino.
Si los activos son vectores (como texto? Fuentes?) No es el cálculo de la colocación de subpíxeles automática/matemática? ¿O estoy equivocado? –
Eso suena como una decisión de implementación. Uno podría tener 4 representaciones en el disco, o computar 4 representaciones en el momento de la instalación (y almacenarlas en el disco) o calcular 4 representaciones cuando la fuente se carga en la memoria, o computar las representaciones de forma perezosa a medida que el dispositivo responde a la reorientación. Sin importar lo que elijas, simplemente estás cambiando el costo de un lugar a otro, sin deshacerte de él. Cualquiera de estos puede no ser el uso más juicioso de los recursos en un mundo móvil donde el almacenamiento, la memoria y la CPU deben usarse todos de forma parsimoniosa. – pohl