Si tu le fais, tu te retrouves avec un buffer cote GPU qui n'est pas dans son format interne et tu perds en performance (Cela se sent pas mal sur les GPU ARM, moins sur Intel). De plus dans toutes les implementations que j'ai vu sur ARM, celui-ci forcait un stall du pipeline cote GPU (Theoriquement non necessaire, si on a des texture double bufferises mais je n'ai jamais vu d'implementation qui faisait cela (je n'ai pas regarder ce que faisait mon intel)). Il ne faut pas oublier qu'un compositeur a la difference d'un jeu, va updater ses textures quasiment a chaque frame. Ceux sont donc des problemes que seul les compositeurs voient. Le fait est que les drivers sont pour l'instant optimise pour les jeux pleines ecran lorsque le compositeur est desactive et qu'il y a encore beaucoup de boulot de ce cote la.
Je suppose que tu parles de perdre le tiling sur le BO. T'es pas obligé de le perdre si tu le refais avec ton CPU. Mais bon, tu peux tjs rendre la différence sur ton CPU et demander à la carte de faire le blit sur le buffer actuel. Pas besoin de faire un accès direct ni de re-rendre toute l'image.
Je referais le test dimanche, mais tu as teste avec quoi ?
J'étais sous KDE. Yakuake de lancé et qui prenait le quart haut de l'écran. Dedans y'avais une appli qui me donne la conso toute les secondes (qui avait été dev par un pote, c'est pas public).
Pour le test idle, je ne faisais rien de plus que regarder la conso une fois qu'elle s'était stabilisée.
Pour le test en bougeant une fenêtre, je faisais juste bouger une fenêtre dans les 3/4 d'écran qu'il reste.
Clairement la standardisation de l'API pour manipuler les plans ouvrent un certain nombre de chose tres interressante cote toolkit, mais il y a du boulot !
C'est pas au toolkit de gérer ça. Y'a que le compositeur qui peut les utiliser ou, au moins, les attribuer à des clients graphiques. Ces clients n'ont jamais à gérer l'affichage dans Wayland, ils ne font que rendre des buffers. C'est pour ça qu'à terme, ils devront uniquement utiliser des render nodes.
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 3.
Je suppose que tu parles de perdre le tiling sur le BO. T'es pas obligé de le perdre si tu le refais avec ton CPU. Mais bon, tu peux tjs rendre la différence sur ton CPU et demander à la carte de faire le blit sur le buffer actuel. Pas besoin de faire un accès direct ni de re-rendre toute l'image.
J'étais sous KDE. Yakuake de lancé et qui prenait le quart haut de l'écran. Dedans y'avais une appli qui me donne la conso toute les secondes (qui avait été dev par un pote, c'est pas public).
Pour le test idle, je ne faisais rien de plus que regarder la conso une fois qu'elle s'était stabilisée.
Pour le test en bougeant une fenêtre, je faisais juste bouger une fenêtre dans les 3/4 d'écran qu'il reste.
C'est pas au toolkit de gérer ça. Y'a que le compositeur qui peut les utiliser ou, au moins, les attribuer à des clients graphiques. Ces clients n'ont jamais à gérer l'affichage dans Wayland, ils ne font que rendre des buffers. C'est pour ça qu'à terme, ils devront uniquement utiliser des render nodes.