Nop, il faut une "négociations", sinon tu te retrouve a devoir gérer plus d'information côté compositer que nécessaire ! De plus les sub surface ne gèrent pas le clipping de manière suffisante si je me souviens bien pour cette tâche. Il sera nécessaire d'étendre le protocole.
Euh, même si tu faisais de la négociation, tu seras toujours obligé de supporter l'upload des BO sur planes et le compositing GL du reste. Du coup, je vois pas ce que ça t'apporte en terme de complexité si ce n'est de rendre l'exécution des applications plus complexe (imagine les cas où 3 planes seront dispo, ça marche et quand y'en a 4 ou 6, ça marche plus, va debugger ça!).
Pour les subsurfaces qui supportent mal le clipping, faut étendre le protocole.
Je ne vois pas pourquoi. Tu as de toute façon accès a tous les buffer. Mais je n'ai pas regarder cette aspect plus que de manière théorique pour l'instant.
Au final, ce que tu proposes, c'est de faire exactement ce que je propose avec en plus une phase de négociation pour le nombre de plane. Ça n'a de sens que si tu veux garantir des performances GL. Ça me semble vraiment pas utile vu le coup du compositing.
[^] # 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é à 4.
Euh, même si tu faisais de la négociation, tu seras toujours obligé de supporter l'upload des BO sur planes et le compositing GL du reste. Du coup, je vois pas ce que ça t'apporte en terme de complexité si ce n'est de rendre l'exécution des applications plus complexe (imagine les cas où 3 planes seront dispo, ça marche et quand y'en a 4 ou 6, ça marche plus, va debugger ça!).
Pour les subsurfaces qui supportent mal le clipping, faut étendre le protocole.
Au final, ce que tu proposes, c'est de faire exactement ce que je propose avec en plus une phase de négociation pour le nombre de plane. Ça n'a de sens que si tu veux garantir des performances GL. Ça me semble vraiment pas utile vu le coup du compositing.