Actuellement SurfaceFlinger passe par la 3D, le rendu 2D n'est plus supporté par Google, seul les fabriquants remettent en place celui-ci pour des raisons de coûts de développement.
Pas pour des questions de cout de developpement, pour des questions d'economies de batterie. L'accelerateur 2d consomme un ordre de grandeur moins que l'accelerateur 3d. Sans compter que etant une unite separe celui-ci n'impacte pas les performances lorsque le compositing fonctionne. Son absence peut se remarquer assez facilement, car le telephone se met a lagguer des qu'il y a un layer transparent au dessus. Exemple probable, le dernier LG permet de prendre des notes en transparence sur les applications. Mais des que tu as ce layer transparent, le telephone ne tiens plus du tout les 60fps. C'est donc assez flagrant comme probleme, meme sur les telephones de derniere generation.
Dire que Wayland est mieux par ce que c'est développé par d'autres que Google, c'est tiré par les cheveux. Wayland est un gros mangeur de ressources et surtout de batterie, pas besoin de benchmark il suffit de regarder la gestion du flip des images dans le code. Ou encore de voir qu'en mode SHM (seul mode disponible sur des petits processeurs), il est impossible d'accéder directement à la mémoire vidéo et donc d'avoir des copies de mémoire. Je sais que c'est pour des raisons de sécurité, mais des fois il faut chercher d'autres solutions.
Non, je dis que Wayland est developpe par un certain nombre d'individu travaillant pour un large eventail de societe avec des objectifs divers. Cela conduit forcement a realiser quelque de chose de plus efficace et generique.
Alors le role d'un compositeur, que ce soit X ou Wayland ou quelqu'il soit dont le but est de faire du multi-application ne peut pas se permettre de donner acces directement a la memoire. Si tu veux acceder directement a la memoire, tu fais ton application sur le frame buffer.
Maintenant ton hardware n'est pas si limite. 400Mhz et 256MB, c'est plutot dans la categorie luxueux pour moi ! On est pas loin de pouvoir faire tourner un desktop complet avec tout ca ;-) Je suis meme pres a parie que tu as une unite d'acceleration 2D ou au moins la gestion de plusieurs plan graphique. Largement de quoi faire tourner un Wayland. Il te manque probablement un driver KMS/DRM pour l'allocation des buffers. Et il n'y a rien qui force dans Wayland a avoir une implementation 3D pour travailler sur des buffers video. Tu peux alors directement alouer des buffer hardware et faire une implementation derriere en soft. La derniere fois que j'avais regarde ce scenario, on devait pouvoir s'en sortir en reutilisant une toute petite partie de EGL. Enfin tout depend apres du nombre d'application a gerer, mais tu dois pas en avoir beaucoup en simultanee vu le materiel, donc laisser Wayland leur donner a chacune un layer graphique doit etre le plus efficace.
Au final, le plus couteux sera la vitesse du backend software de ton toolkit graphique et DirectFB n'est pas bon de ce cote la. Bien entendu, si tu ne veux pas faire du multi application, mais juste avoir des fenetres dans une seule application. Pas la peine de t'ennuyer avec tout ca. Tu prend juste le framebuffer et roule avec les EFL. Peut etre un backend specifique pour tirer partie de l'acceleration 2D, si elle est un minimum utile. Et la, tu auras la solution la plus efficace et versatile.
[^] # Re: Waylands et Mir ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 7.
Pas pour des questions de cout de developpement, pour des questions d'economies de batterie. L'accelerateur 2d consomme un ordre de grandeur moins que l'accelerateur 3d. Sans compter que etant une unite separe celui-ci n'impacte pas les performances lorsque le compositing fonctionne. Son absence peut se remarquer assez facilement, car le telephone se met a lagguer des qu'il y a un layer transparent au dessus. Exemple probable, le dernier LG permet de prendre des notes en transparence sur les applications. Mais des que tu as ce layer transparent, le telephone ne tiens plus du tout les 60fps. C'est donc assez flagrant comme probleme, meme sur les telephones de derniere generation.
Non, je dis que Wayland est developpe par un certain nombre d'individu travaillant pour un large eventail de societe avec des objectifs divers. Cela conduit forcement a realiser quelque de chose de plus efficace et generique.
Alors le role d'un compositeur, que ce soit X ou Wayland ou quelqu'il soit dont le but est de faire du multi-application ne peut pas se permettre de donner acces directement a la memoire. Si tu veux acceder directement a la memoire, tu fais ton application sur le frame buffer.
Maintenant ton hardware n'est pas si limite. 400Mhz et 256MB, c'est plutot dans la categorie luxueux pour moi ! On est pas loin de pouvoir faire tourner un desktop complet avec tout ca ;-) Je suis meme pres a parie que tu as une unite d'acceleration 2D ou au moins la gestion de plusieurs plan graphique. Largement de quoi faire tourner un Wayland. Il te manque probablement un driver KMS/DRM pour l'allocation des buffers. Et il n'y a rien qui force dans Wayland a avoir une implementation 3D pour travailler sur des buffers video. Tu peux alors directement alouer des buffer hardware et faire une implementation derriere en soft. La derniere fois que j'avais regarde ce scenario, on devait pouvoir s'en sortir en reutilisant une toute petite partie de EGL. Enfin tout depend apres du nombre d'application a gerer, mais tu dois pas en avoir beaucoup en simultanee vu le materiel, donc laisser Wayland leur donner a chacune un layer graphique doit etre le plus efficace.
Au final, le plus couteux sera la vitesse du backend software de ton toolkit graphique et DirectFB n'est pas bon de ce cote la. Bien entendu, si tu ne veux pas faire du multi application, mais juste avoir des fenetres dans une seule application. Pas la peine de t'ennuyer avec tout ca. Tu prend juste le framebuffer et roule avec les EFL. Peut etre un backend specifique pour tirer partie de l'acceleration 2D, si elle est un minimum utile. Et la, tu auras la solution la plus efficace et versatile.