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.
![Imágenes en 500 bytes: el formato de imágenes vectoriales de Haiku [ENG]](https://cdn.mnmstatic.net/cache/28/b2/media_thumb_2x-link-2667223.jpeg?1473008527)
Comentarios
Me encanta la vectorización. Eso de poder reescalar con pérdida de calidad 0% es casi mágico. Además de que desde el punto de vista de la eficiencia, es lo óptimo, tanto en peso como en calidad.
#11 el problema es el gasto de cpu cada vez que tengas que renderizar el gráfico, aunque si las gpus pudieran hacer ese trabajo igual van más rápidos que los bitmaps.
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
#18 El objetivo es que pesen poco para evitar hacer peticiones adicionales. Si haces un cache de memoria en bmp, pues al final solo la primera llamada consigue el objetivo mientras que el resto no.
#26 el artículo dice que es para reducir operaciones de disco, una cache en memoria siempre reduce operaciones de disco. De hecho es al revés de como dices con una cache la primera imagen se lee se calcula y se usa, en el resto solo se usa.
#26 Si guardas el bitmap en memoria de video sólo procesas la primera vez y luego tiras de caché de bitmaps en memoria de video, por lo tanto no vuelves a leer de disco; aunque lo ideal sería que los iconos se almacenaran o renderizaran en un formato vectorial que entendiera la gpu y fuera esta la que hiciera todo el trabajo una vez leidos de disco.
#33 Correcto. Pensaba que quwrias dejarlo en el hdd y no en la memoria rapida.
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).
#38 viéndolo así... dan ganas de no hacer SO, hagas lo bueno que lo hagas llegara alguien con un programa que se coma los recursos y haga el equipo inutilizable.
#26 Si no entendí mal, el artículo habla de evitar hacer lecturas de disco, que son lentas, pero creo que #18 se refiere a una cache en memoria física (la RAM, para entendernos), que es rápida.
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.
#34
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.
#18 Estoy de acuerdo contigo. El principal problema puede ser el tiempo de renderizado, el gasto de CPU. Si el tiempo que ahorras en lectura de disco lo gastas en renderizado pues mal negocio ¿no? Aparte, un BMP no tiene por qué ir en un fichero aparte ¿o me equivoco? (esa parte no la entendí muy bien... por ejemplo, creo que los ejecutables tienen un icono ¿BMP? codificado en el propio fichero ¿o no?)
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).
#39 Creo que renderizar imágenes vectoriales "sencillas" (que es lo que se pretende con iconos y similares) no supone un gran trabajo para la CPU (o GPU). Para imágenes complejas mejor un formato de imagen comprimida y a correr. Las imágenes vectorizadas también tienen mucha utilidad para logos de marcas que vas a tratar en muchos tamaños distintos, pero ahí ya ni te importa el tiempo de renderización porque vas a generar un PNG (o similares) para cada tamaño.
#39 Aparte, un BMP no tiene por qué ir en un fichero aparte ¿o me equivoco? (esa parte no la entendí muy bien...
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í).
#18 Mejor tirar de CPU o de hardware dedicado a estos menesteres en la gráfica, que tirar de peticiones de red.
#51: Este formato para Web parece muy interesante, sobretodo si se permite usar compresión, porque SVG está bien pero ocupa mucho pudiendo ocupar menos.
#18 Dependiendo del dispositivo de almacenamiento y de la CPU, puede darle tiempo a renderizar muchas veces el gráfico en lo que de otra forma tendría que esperar a terminar de leerlo "del disco".
#11 Y también lo peor, en cuanto a eficiencia de cálculo.
Nadie piensa en el cambio climático?
#7 Yo usé BeOS en una máquina antigua y podía hacer cosas impensables en Windows.
#10:
#23 yo tuve Beos, y en aquel momento el rendimiento gráfico daba hasta miedo. Acojonante se quedaba corto. Pero el projecto se quedó en eso, y no era practicable para la vida real.
#6 Para eso también tenemos SSysDevs
#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
#58 ¿Hayku (BeOs) competencia directa de Windows 95? Ni en sus mejores sueños.
Que existieran en la misma época no le convertía en competencia.
#10
#10 Yo también llegué a instalar BeOS tanto en una VM como en mi antiguo PC. ¿Qué cosas impensables en Windows podías hacer?
#10 ¿Por ejemplo?
Yo tengo siempre dos maquinas virtuales: una con Haiku y otra con ReactOS.
Hay
vidaopensource mas alla de Gnu/Linuxy Windows...por mucho que se empeñen en lo contrario#21 y como sistema host qué tienes, si no es indiscreción?
#31 FreeBSD
#21 Nadie se empeña en lo contrario, pero hay cosas más útiles que otras. A mi los iconitos me importan un carajo.
Un s.o. empeñado en ser supereficiente tiene su coste pero tambien su potencial nicho de mercado. Bien por Haiku por seguir en esa linea.
¿Usa alguien Haiku? No, es en serio, desconocía este OS. Pregunto por el comentario de #2 donde asegura que es supereficiente.
#7 hay gente que lo usa, he de decir que cuando lo he probado va como un tiro, ojalá soportara mis herramientas de desarrollo... Le iban a dar al Linux...
#8 Gracias amigo.
IRIX, el UNIX de Silicon Graphics, ya usaba iconos vectoriales.
#15 #16 ¿Cuánto ocupaban?
Para mi gusto lo interesante es por qué quieren tener iconos de 500 bytes, el resto viene rodado cualquier equipo llegaría a mismo o similar formato si les obligan a tener iconos de 500 bytes. Para qué reducirlo tanto? no es por calidad, tampoco por ahorrar espacio en disco, es por velocidad pero el tamaño de un icono solo afecta a cuando lo quieres leer del disco para enseñarlo eso normalmente es cuando en el explorador abres una carpeta el sistema operativo mira en la tabla de ficheros del disco que ficheros hay para enseñártelos esta tabla tiene los nombres y sectores usados por cada fichero, luego para cada fichero tiene que ir a sus sectores y leer el icono de marras. Eso implica leer unos pocos sectores para consultar la tabla de disco y luego tantas operaciones de disco como ficheros haya, son esta segunda parte de operaciones de disco las que quieren ahorrarse. Si la tabla de disco tuviera los nombres, los sectores ocupados y los iconos todo se reduciría a leer unos pocos sectores de la tabla de disco y nada mas. La tabla de disco se usa para cientos de cosas hacerla de tamaño mas grande implica mas trabajo para otras muchas cosas para las cuales los iconos no pintan nada, de ahí que si se quiere tener los iconos ahó tienen que tener el menor tamaño posible tanto como 500 bytes. Una vez fijado ese límite de 500 bytes como ya dije al principio dudo que nadie optara por ninguna otra solución que la encontrada usar un formato vectorial.
#67 Ya lo puse en el primer párrafo, hoy en día los accesos a disco también son importantes, si me pones de ejemplo un teléfono móvil más aún.
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?
#65 "Esta tontería" va orientada a reducir el número de operaciones de disco, no el tamaño leído que es secundario (y algo despreciable hoy día, tal como ya señala el artículo), que es una cosa en la que precisamente las memorias de móvil son bastante malas.
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...
#66 veamos... Lo que dudo es de la eficiencia de todo el conjunto. Lo de menos accesos al "disco" pues.. como que hoy en dia es más que irrelevante. A lo mejor en discos mecánicos puede que se note, pero hay un invento nuevo, el SSD, que vas a alucinar cuando lo veas.
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.
En otro orden de cosas, un formato de imagen hecho para ser comprimido y que su tamaño con GZIP / XZ sea menor que un PNG manteniendo toda la calidad:
http://tools.suckless.org/farbfeld/
Hay Bender, hay meneo.
Llega la era de los ssd y ahora nos preocupamos por un acceso a disco...
#40 por supuesto los SSD son mucho más rápidos pero no para tanto.
#46 Que va, de pocas centenas de iops a decenas de miles. No es para tanto.
#48 pero no como para no preocuparse, con SSD las operaciones de disco siguen siendo las mas lentas.
#48 Hasta los miles de millones de instrucciones por segundo de una CPU, sí es para tanto.
#63 espera, espera, que #46 hablaba de discos, de ahí lo de IOPS, que no tiene nada que ver con las IPS de una CPU.
#64 "Esperar" es lo que hace la CPU cuando pide datos del disco, y el disco (SSD) tarda lo mismo que 100.000 instrucciones de CPU para entregarle los datos que ha pedido.
¿Que no tiene nada que ver? y una leche.
#76 pero tu estas contestando solo por hacerte el gracioso y llevarte karma, o sabes de lo que hablas; porque menospreciar una mejora de tres órdenes de magnitud no es como para decir 'no es para tanto'
#79 Pero tú sabes a lo que respondes, o te haces el tonto; porque menosprecias una diferencia de cinco órdenes de magnitud justificando que "oye, ya no son ocho órdenes de magnitud"
#40 Sí, llega la era en la que un procesador puede ejecutar 80.000 instrucciones en lo que tiene que esperar a un SSD, en vez de poder ejecutar 40.000.000 de instrucciones en lo que le tocaba esperar a un HDD... ¿y?
#20 Hombreeee...comprender que es un "inodo" lleva su tiempo :3 De todas formas no es tanto el tamaño(un icono no pasa mas alla de uno cuantos kb) sino reducir el numero de peticiones.
Quién se empaña en lo contrario?? yo llevo años usando (también) FreeBSD.
Lo de ReactOS no lo conozco. Le echaré un vistazo a ver quienes lo hacen...
#57 Dependiendo del dispositivo y el tiempo que pueda permitirse perder presentando unos iconos, sí hay problemas y necesidad. Que no te hayas encontrado con ninguno, no significa que no existan.
La ventaja de no perder calidad en tamaños grandes, es que "grandes" en este caso estamos hablando de 256x256 en una pantalla tamaño móvil de 1920x1080 por ejemplo, que si lo intentas guardar en bitmap te puede ocupar 100 veces más la broma.
#59 ¿Ves el sinsentido? Un móvil con una pantalla de hmmmm 5.5' mostrando un icono de 256x256. Anda que si muestra uno de 128x128 escalado se va a notar. Pero bueno, aceptamos barco. Si el icono tiene 16 bits de color hablaríamos de 16KB. En un 1GB cabrían más de 65.000 iconos de ese tamaño. No son raros los móviles con 32GB. Vamos, que con una foto más o menos que hagas en el móvil vas a notar más la diferencia de almacenamiento que con esta tontería.
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.
#65 "En un 1GB cabrían más de 65.000 iconos de ese tamaño. No son raros los móviles con 32GB"
Irrelevante.
"Si el icono tiene 16 bits de color hablaríamos de 16KB."
En un sistema de ficheros con bloques de 4KB, como suelen ser la mayoría, eso son 4 accesos a disco.
Compara eso con 0 accesos a disco de Haiku porque ya tiene el icono al haberlo leído junto con los metadatos del fichero.
#75 Me has convencido, a ver si lo implementan en Windows 11 y se nota ese hmmmm 0.0000001% más de velocidad.
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
#77 No estoy aquí para convencerte, sino para reírme de lo gilipollas y engreído que eres.
Claramente no entiendes que pueda haber un mundo fuera de tu maquinita de 2000€ modelo gamer con Windows, RAM y disco para tirar. Espero que te lo pases chachi piruli con tus LEDs a ritmo de música chumbeta mientras te fumas el porrito y haces llorar a los nenes en el CoD.
Pero tranqui, cuando el móvil te vaya lento, el display de la lavadora se te cuelgue, o tengas que esperar a reiniciar el coche, puedes estar seguro de que yo estaré aquí partiéndome el culo.
#78 No das ni una. Como vidente no te ganarías la vida.
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.
#81 Cada un poco más, que todavía se ve el cielo.
#78 #81 ¿La lavadora? El display del deco de Euskaltel es un puto engendro que va más lento que la madre que lo parió. No sé si está hecho con HTML5 + JS porque es una verdadera basura.
#84 Seguro que la clave son los iconos. Que los pongan vectoriales que evitan millones de lecturas y fijo que irá todo como la seda. Y hasta necesitará menos detergente y gastará menos luz.
#84 El mío no tenía display, sería un modelo viejo o algo. Posiblemente vaya lento porque ni se molesten en meter un controlador dedicado para el display, sino que la misma CPU se encargue de controlarlo, y tengan que mandar los datos lento de cojones para reducir el jitter hasta algo "razonablemente fiable".
Y no sería mejor utilizar para todo PiedPiper??? Consigue una compresión sin pérdida del 75%...
http://www.piedpiper.com/
Meneo por trolear al usuario promedio. Muy buen artículo por cierto, me encantan las curiosidades de los entresijos de la informática.
Los iconos vectoriales son muy antiguos. Vamos, con GNOME 2 y KDE 3 ya se podían usar.
#3 No es tanto por la calidad sino por el tamaño. Del artículo:
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.
#14 Vale como divertimento, pero ni hay problemas de almacenamiento ni hay necesidad.
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...
Ui si, gran descubrimiento, aprovechar cada bit en vez de usar burradas como XML...
#49
No veo que XML sea tan farragoso.
#71: Y te falta la cabecera, eso si hubiera sido pwneante.
De hecho si hicieran el SVG con opción de guardarse en JSON ganarían mucho.
que no sea de google
#27 Soporta Xamarin Forms y también nativos. Te lo instalas de nuget, y tiras millas.
#35 grache mile! Le daré un ojo seguro
me parece una puta maravilla
200 iconos no son 200 accesos a disco. Son dos accesos a disco: uno para leer un mapa de bits con 200 iconos y dos para leer un fichero con las coordenadas de cada uno de ellos.
Podrías meter todo en unico fichero, pero vamos, ya andarías manipulando los bytes del jpg o el png.
Iconos vectoriales, eso lleva años en GNU/Linux por ejemplo en Gnome2 fue cuando lo descubrí...después la cagaron con el 3...pero menos mal que existe Mate.
#13 la gracia de este formato es que los gráficos sean pequeños y que quepan en un inodo para minimizar la lectura de disco y que carguen más rápido, no el que el gráfico sea vectorial
#19 por fin alguien lo ha comprendido!!!!!
#19 Sigo sin verle la gracia. Cualquier sistema medianamente avanzado tiene una caché de iconos, que además suele ser persistente y no se pierde cuando se reinicia, así que por lo general solo se requiere una lectura de esa caché al arrancar el PC, lo que es un tiempo despreciable comparado con todas las otras cosas que hace un sistema al arrancar.
#44 uf, si supiera desactivar la cache o hacer que se limpiase sola... de vez en cuando tengo que usar un alias que tengo puesto para borrar .thumbnails...
Hay una variación de PNG, PNG de Fireworks, que muchos visores entienden y también es vectorial, nunca entenderé por que no se popularizó más ese formato y la herramienta, son geniales.
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.
#17: ¿No serían PNGs con el código SVG dentro?
Yo lo hago a veces, metiendo el código en el propio SVG mediante un editor de metadatos.
#17 XamSvg, y así tendrás el componente SvgImage que añades directamente en el xaml. En Unity no he probado, pero sí he escuchado que da dolores de cabeza.
#25 gracias! No lo conocía, entiendo que es un componente de xamarin forms y no especifico por plataforma, correcto?
Hasta ahora hemos trabajado en proyectos nativos unificados con xamarin pero sin xamarin forms, lo tendré en cuenta para próximas aventuras.
Yo soy mas del gif...
¿Es tan importante que un iconito tenga mucha calidad gráfica?
#3 No es que tenga mucha calidad gráfica, es que lo puedas escalar tanto como quieras sin perder la mucha o poca calidad que tenga.
#5 exacto, tengo un monitor 4k y tengo que escalar todo y prefiero que se vean bien que una basura.