264 meneos
9999 clics
Imágenes en 500 bytes: el formato de imágenes vectoriales de Haiku [ENG]
El sistema operativo Haiku usa un formato vectorial propio para almacenar iconos, lo que es sorprendente por dos motivos: la mayoría de sistemas operativos consideran los mapas de bits suficientes para representar iconos y ya hay varios formatos vectoriales para representar gráficos (p.e. SVG). La meta del formato HVIF (Haiku Vector Icon Format) es hacer los archivos tan pequeños como sea posible, pero permitiendo mostrar las imágenes sin pérdida de calidad y con un tamaño suficientemente pequeño como para caber en un inode.
|
comentarios cerrados
TL;DR: si el icono fuese tan pequeño como para embeberlo en los metadatos del fichero, te ahorras un acceso de lectura al disco por cada fichero a listar. Al reducir el acceso a disco, se optimizan los tiempos para mostrar archivos.
Why do Haiku’s developers care about the size of icon files?
[...]
If you use the standard bitmap icon formats, you’ll probably store them in their own files, separate from the files that use them. In order to display each file in a folder, the operating system will need to read the metadata for the file and then read the icon file for that file type. If the icon file were so small that you could store it in the same place as the file metadata, then you could save a read from the hard drive – you could get the metadata and the icon all in one read.
Saving one read per file doesn’t sound exciting – it’s just one. However, reading from disk is among the slowest operations.[...]The reads from disk dominate the time it takes to display a file in a folder; it could be a significant performance gain to halve the number of disk reads even if rendering a vector image takes longer than rendering a bitmap.
Edit: CC #13, #15
Respecto a los SVG.. Anda que no se utilizan hace tiempo para cientos de cosas... Por desgracia todavía son de dificil integración en algunos motores/entornos.
Por ejemplo, Unity no entiende vectoriales de forma nativa, en Visual Studio + Xamarin es dificilisimo...
Pero hay muchas webs que ya lo utilizan en todo.
Otra opción seria hacer caches en memoria con el gráfico renderizado a bitmap para no tener que recalcular nada cada vez que el icono se redibuje
Hay
vidaopensource mas alla de Gnu/Linuxy Windows...por mucho que se empeñen en lo contrarioYo lo hago a veces, metiendo el código en el propio SVG mediante un editor de metadatos.
Hasta ahora hemos trabajado en proyectos nativos unificados con xamarin pero sin xamarin forms, lo tendré en cuenta para próximas aventuras.
Lo de ReactOS no lo conozco. Le echaré un vistazo a ver quienes lo hacen...
Ya sabes, con 'disco' nos referimos a cosas como el disco duro... que es no volátil y más barato por unidad de memoria, pero tiene la pega de ser más lento. Y por 'memoria' solemos hacer referencia a cosas como la RAM, que volátil y cara pero mucho más rápida.
Nadie piensa en el cambio climático?
De todas formas yo siempre que leo esto de las microptimizaciones me hace sonreir. El SO preocupado por facilitar ganar unos microsegundos y los navegadores web consumiendo, por poner un ejemplo, 50 MB por pestaña que al final obliga a estar paginando memoria(probablemente el IO mas caro que existe).
Creo que decir que un formato es "el óptimo" o que es "el mejor", como dijo #11 , sin decir en qué casos es 'mejor' o bajo cuáles métricas o parámetros se evalúa si es mejor o no... pues no me parece del todo correcto.
Esto ocurre en muchos casos: que si un lenguaje de programación es "el mejor" o es "mejor que otro", que si un Sistema Operativo es 'mejor', que si un coche es "el mejor"... pues, hombre, depende de para qué o para quién ¿no? Un coche puede ser el mejor en velocidad pero muy malo en consumo y muy caro en precio (deportivos de lujo, Formula 1, etc). Otro coche todoterreno puede ser el mejor en el campo pero no será muy aerodinámico en carretera. Otro puede ser muy "fiable" porque se averíe muy poco, pero a lo mejor no es el más barato ni el más veloz. Otro puede ser el más barato pero no ser el más veloz ni el más seguro (seguridad activa y pasiva) ni el más fiable (se avería mucho).
Sep. Pero por alguna razon me imaginaba generando bmps del svg en el hdd. Probablemente sea por el proyecto en el que estoy metido ahora que generamos imagenes combinando otras y demas y me he hecho un "biasing" a mi mismo.
tools.suckless.org/farbfeld/
www.piedpiper.com/
Hay cosas que no se van a poder hacer con un vector, como el icono de una foto con algo real, como una cara o una fotografía.
Por otro lado... ¿qué ventajas tiene poder representar el dibujo sin pérdida de calidad en tamaños grandes si un icono es por definición un dibujo pequeño?
En fin...
#29 En realidad sí era practicable en la vida real. De hecho era competencia directa de Windows 95. El problema fueron los recursos de cada compañía. A Be Inc. no le llegaron. Microsoft iba sobrada.
/cc #23
Pero bueno, que como ejercicio informático es curioso.
En plan abogado del diablo a lo mejor hasta gasta más batería renderizar el icono vectorial que simplemente leer un bitmap tal cual.
Pero bueno, me hace gracia como aquí la mayoría de comentarios están diciendo cosas que se leen tal cual en el artículo enlazado como queriendo llevarle la contraria y ser más listos...
Tenemos por ejemplo a quien cree que esto se trata de una noticia de actualidad o que intenta vender los gráficos vectoriales como algo nuevo cuando el formato lleva una década, hablando de GNOME y KDE (ni que fuesen precursores en imágenes vectoriales o marcasen tendencia en eso).
También hay quien siente indiferencia de la optimización por la llegada de los SSD cuando ya en el artículo ni se molestan en poner las órdenes de magnitud que la CPU espera en acceso a disco de platos, sino que lo hace directamente indicándolo sobre SSD.
Pero nada, luego nos quejaremos cuando el móvil empiece a ir lento con las actualizaciones, cuando el navegador consuma RAM y CPU a saco... para unos que intentan optimizar y no desperdiciar recursos y aquí todo el mundo despreciando la idea (y no son los únicos, pero los demás que parten de esa filosofía no son mucho más populares).
Parece que aquí nadie ha tenido que esperar de brazos cruzados la construcción de "thumbnails" de Windows en carpetas grandes...
Desventajas:
- Limitación a la hora de diseñar iconos (¡en pleno siglo XXI!)
- Nuevas herramientas respecto a las actuales.
- Más código que consume más CPU que lo que hay hasta ahora.
Ventajas:
- Iconos vintage Windows 3.1 que puedes escalarlos hasta cubrir la fachada de un edificio sin que pixele.
Es correcto lo que dices. Lo que te faltó para entender esa parte es el concepto de inode (o igual ya lo tienes pero te faltó vincularlo). El inode es el bloque básico de información del fichero, es metainformación y no tiene contenido real. Por ejemplo guardaría el tamaño, fecha de creación, permisos, puntero al contenido... eso se lee antes de acceder al contenido en sí. Es más, puede que el contenido no llegues a leerlo nunca.
Si metes el icono en el ejecutable, tal como dices, al abrir una carpeta el sistema tiene que leer el inode para ver esa información que va a resumir y mostrarte (carpeta con 12 archivos ocupando 50 MB en total). Luego tendría que saber que es un ejecutable y que posiblemente tenga un icono integrado, así que leerá el principio del contenido esperando encontrar esa información y, si tiene éxito y realmente hay un icono, tendrá que ir a leer la parte donde está el icono. En total tiene que leer tres direcciones mínimo (inodo, inicio del contenido y posición del icono en el contenido).
El truco es que si metes el icono en el inodo ya no tienes que acceder al contenido para nada (lo cual, ahora que caigo, es más seguro también, ya que el contenido puede tener algún truco para inyectar código malicioso al intentar obtener el icono, con lo que tendrías un virus antes de haber ejecutado nada siquiera). El problema es que el inodo sólo ocupa lo que un sector de disco (la mínima unidad que le puedes pedir que te envíe), por lo que el espacio para hacer eso es muy reducido (si no ya lo harían todos así).
Lo han puesto varios usuarios ya, y el artículo ya parte explicando la situación con un SSD. Hoy en día la CPU espera un poco menos por cada lectura a disco, pero sigue esperando varios miles de operaciones en los cuales ya le ha dado tiempo a renderizar 100 iconos vectoriales.
En cuanto a las limitaciones artísticas, bueno, es una preocupación legítima. De todos modos, el problema en mi opinión con los bitmaps es que la resolución que hoy es suficiente dentro e 3 años igual queda como el culo reescalada. Y puestos a hacer vectores pues si logras que quepan en el inode para ahorrar un (aún hoy en día costoso) acceso a disco, pues mejor ¿No?
<Respuesta origen="49">
<párrafo class="inline">
<línea value="1">
No veo que XML sea tan farragoso.
</línea>
</párrafo>
</Respuesta>
</Hilo>
De hecho si hicieran el SVG con opción de guardarse en JSON ganarían mucho.
Por no hablar de la de espacio que nos vamos a ahorrar. Ahora que cada vez el almacenamiento está más caro y lento seguro que se aprecian esos hmmmm.. lo menos 40MB de ahorro en esos discos de 500.000MB.
Bien valdrá la pena currarse esos iconos, va a haber un antes y un después de la velocidad y el almacenamiento de los PCs.
Lástima no lo hubieran sacado cuando el spectrum, no hubiera hecho falta el modelo 128K, Linux hubiera corrido en el zx80
Que existieran en la misma época no le convertía en competencia.
Entonces... ¿lo van a implementar en la lavadora? Joder, esto sirve hasta para centrifugar más rápido!
PD. Vendo Opel Corsa rapidísimo con iconos vectoriales.
Podrías meter todo en unico fichero, pero vamos, ya andarías manipulando los bytes del jpg o el png.