Alors pour ce qui est de Samsung. Le travail concerne principalement l'amelioration du toolkit Elementary pour supporter un maximum de cas d'usage pour l'embarque (telephone, tv, appareil photo, camera, imprimante, tablette, netbook, …) ou desktop. Le deuxieme axe, c'est l'amelioration des performances aussi bien diminution de la consommation memoire que l'augmentation des performances du rendu GPU et CPU.
Je n'ai pas trop une vision actuelle de ce qui de Elementary. De ce que j'en sais, il y a du travail de fait pour ameliorer la navigation a la telecommande et ameliorer l'accessibilite du toolkit.
Par contre pour l'amelioration des performances, j'ai nettement plus d'information puisque c'est la partie sur laquelle je travaille. Tout d'abord les choses certaines, amelioration de la boucle de rendu principale pour la rendre plus maintenable et performante. On va la rendre asynchrone par defaut pour tous les backend (Ca veut dire que les EFL ne pourront a partir de la prochaine version plus tourner sans thread). Toutes les ressources graphiques seront aussi partage entre les applications (cela inclu image et glyph de font). Cela devrait permettre une moindre consommation memoire et un meilleur temps de demarrage. Ca c'est pour ce qui est sur.
Maintenant plus pour le cote recherche, un certain nombre d'algorithm de rendu son limite par la bande passante memoire. On est donc entrain d'experimente la compression des ressources graphiques du theme et des fonts avec un rendu direct. Cela pourrait augmenter la charge CPU, en diminuant la bande passante memoire consome, donc prendre moins de temps au final. La plus grosse question sera de voir si cela a un impact sur la consommation de batterie. On travaille aussi sur un moteur de rendu hybride GPU/CPU, car OpenGL n'est pas adapte a toutes les situations et il vaudrait mieux pour certain morceaux de l'image finale, passe par le CPU. Enfin pour ameliorer les performances, on espere pouvoir experimente avec un rendu par tile plus adapte a une meilleure utilisation du cache L1.
Enfin, ce que je rajoute dans la categorie optimisation, c'est le passage a une API et a notre propre modele objet. L'objectif est d'amener un certain nombre d'amelioration de debuggage d'abord et aussi d'amelioration des performances en optimisant l'allocation memoire. Contrairement au modele GObject par exemple, les principales contraintes de ce design sont d'avoir moins de code a ecrire qu'avant, avoir un meilleur layout memoire et une grande facilite de debuggage. Viendra aussi avec la generation automatique de binding, mais pas via introspection au runtime, mais par analyse a la compilation. Cela permettra de maintenir de bonne performance meme pour les bindings.
Quand a la finalite de ces travaux, pour Samsung, c'est Tizen.
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par cedric . En réponse à la dépêche Sortie des EFL 1.2.0 et autres illuminations. Évalué à 10.
Alors pour ce qui est de Samsung. Le travail concerne principalement l'amelioration du toolkit Elementary pour supporter un maximum de cas d'usage pour l'embarque (telephone, tv, appareil photo, camera, imprimante, tablette, netbook, …) ou desktop. Le deuxieme axe, c'est l'amelioration des performances aussi bien diminution de la consommation memoire que l'augmentation des performances du rendu GPU et CPU.
Je n'ai pas trop une vision actuelle de ce qui de Elementary. De ce que j'en sais, il y a du travail de fait pour ameliorer la navigation a la telecommande et ameliorer l'accessibilite du toolkit.
Par contre pour l'amelioration des performances, j'ai nettement plus d'information puisque c'est la partie sur laquelle je travaille. Tout d'abord les choses certaines, amelioration de la boucle de rendu principale pour la rendre plus maintenable et performante. On va la rendre asynchrone par defaut pour tous les backend (Ca veut dire que les EFL ne pourront a partir de la prochaine version plus tourner sans thread). Toutes les ressources graphiques seront aussi partage entre les applications (cela inclu image et glyph de font). Cela devrait permettre une moindre consommation memoire et un meilleur temps de demarrage. Ca c'est pour ce qui est sur.
Maintenant plus pour le cote recherche, un certain nombre d'algorithm de rendu son limite par la bande passante memoire. On est donc entrain d'experimente la compression des ressources graphiques du theme et des fonts avec un rendu direct. Cela pourrait augmenter la charge CPU, en diminuant la bande passante memoire consome, donc prendre moins de temps au final. La plus grosse question sera de voir si cela a un impact sur la consommation de batterie. On travaille aussi sur un moteur de rendu hybride GPU/CPU, car OpenGL n'est pas adapte a toutes les situations et il vaudrait mieux pour certain morceaux de l'image finale, passe par le CPU. Enfin pour ameliorer les performances, on espere pouvoir experimente avec un rendu par tile plus adapte a une meilleure utilisation du cache L1.
Enfin, ce que je rajoute dans la categorie optimisation, c'est le passage a une API et a notre propre modele objet. L'objectif est d'amener un certain nombre d'amelioration de debuggage d'abord et aussi d'amelioration des performances en optimisant l'allocation memoire. Contrairement au modele GObject par exemple, les principales contraintes de ce design sont d'avoir moins de code a ecrire qu'avant, avoir un meilleur layout memoire et une grande facilite de debuggage. Viendra aussi avec la generation automatique de binding, mais pas via introspection au runtime, mais par analyse a la compilation. Cela permettra de maintenir de bonne performance meme pour les bindings.
Quand a la finalite de ces travaux, pour Samsung, c'est Tizen.