De la même manière que le rendu de la page d'accueil ne passe pas son temps à aller lire les fichiers des icônes
Justement, non, la gestion de la memoire d'ios est basee autour du concept de "libere les vues qui ne sont pas a l'écran pour liberer de la RAM". Typiquement, les images sont les premieres a passer a la trappe, et je suis intimement persuade que springboard fait tres attention a laisser le plus de RAM possible a l'appli en premier plan.
Springboard ne passe pas son temps a lire les icones, mais c'est clairement fait de facon "faineante" (lazy fetching). Ce qui veut dire que le SVG serait interprete juste avant d'etre affiche. Apres, ya moyen de faire un rendu initialement, au moment de l'installation et de cacher ca sur le disque.
Disons que le choix du SVG n'est pas trivial a faire.
Si ce rendu initial semble prohibitif (ça augmenterait le temps de démarrage par exemple), on trouve maintenant des algos de rendus vectoriel qui tournent essentiellement sur GPU et sont très rapides.
Ca se discute. Entre faire un mmap d'un PNG, le décompresser (peu couteux) et le ploper dans un buffer, voire ploper le PNG direct dans le buffer, et se fader un parsing SVG + devoir descendre dans le GPU et le reveiller pour le mettre en mode "mouline comme un bourrin", ya un monde. J'ai pas de chiffres a avancer, mais vu comment CoreGraphics performe bien sur des bitmaps, particulierement les PNG, je suspecte que c'est une bonne raison pour ne pas utiliser SVG (sans meme mentionner le fait que t'es oblige de ne supporter qu'un subset de SVG, pas d'animation ni rien, ce qui ouvre tout un tas d'autre problemes).
[^] # Re: Y aquandmêmeuntruc que je n'aime vraiment pas
Posté par groumly . En réponse au journal Kernel.org change de peau. Évalué à 1.
Justement, non, la gestion de la memoire d'ios est basee autour du concept de "libere les vues qui ne sont pas a l'écran pour liberer de la RAM". Typiquement, les images sont les premieres a passer a la trappe, et je suis intimement persuade que springboard fait tres attention a laisser le plus de RAM possible a l'appli en premier plan.
Springboard ne passe pas son temps a lire les icones, mais c'est clairement fait de facon "faineante" (lazy fetching). Ce qui veut dire que le SVG serait interprete juste avant d'etre affiche. Apres, ya moyen de faire un rendu initialement, au moment de l'installation et de cacher ca sur le disque.
Disons que le choix du SVG n'est pas trivial a faire.
Ca se discute. Entre faire un mmap d'un PNG, le décompresser (peu couteux) et le ploper dans un buffer, voire ploper le PNG direct dans le buffer, et se fader un parsing SVG + devoir descendre dans le GPU et le reveiller pour le mettre en mode "mouline comme un bourrin", ya un monde. J'ai pas de chiffres a avancer, mais vu comment CoreGraphics performe bien sur des bitmaps, particulierement les PNG, je suspecte que c'est une bonne raison pour ne pas utiliser SVG (sans meme mentionner le fait que t'es oblige de ne supporter qu'un subset de SVG, pas d'animation ni rien, ce qui ouvre tout un tas d'autre problemes).