DRI2 X ne marche que pour les applications OpenGL.
Si le toolkit gère OpenGL, l'application devient OpenGL de facto, non?
Je pense à GTK+ et Cairo (je ne pense pas que Qt ai l'équivalent).
Avec Wayland, toutes les applis utiliseront l'équivalent de DRI2.
Pour pinailler un peu: il y a un exemple de client Wayland utilisant la mémoire partagée, mais on peut espérer que ce soit rare en pratique en effet.
[coupé]Dans le mode raster, il[Qt] utilise son moteur interne pour faire le rendu puis il envoie les modifs complètes via la socket vers X.
Où en mémoire partagée en local.
Avec wayland, ça ira encore plus vite car on aura même plus besoin de sérialiser les commandes ou l'image finale dans une socket et traiter le rendu de toutes les applis dans une thread unique (X).[coupé] Plus de sérialisation du rendu, plus d'utilisation d'un toolkit 2D très limité (X11/XRender).
Il me semble que dans le mode Qt/raster ou OpenGL(DRI2), il n'y ni sérialisation, ni utilisation d'un toolkit 2D puisque dans les 2 cas, le client peut écrire dans son buffer lui-même et envoyer le résultat par mémoire partagée(Qt raster) ou buffer vidéo (DRI2), non?
Après le compositing est sérialisé, mais bon c'est aussi le cas pour Weston.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par reno . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 3.
Si le toolkit gère OpenGL, l'application devient OpenGL de facto, non?
Je pense à GTK+ et Cairo (je ne pense pas que Qt ai l'équivalent).
Pour pinailler un peu: il y a un exemple de client Wayland utilisant la mémoire partagée, mais on peut espérer que ce soit rare en pratique en effet.
Où en mémoire partagée en local.
Il me semble que dans le mode Qt/raster ou OpenGL(DRI2), il n'y ni sérialisation, ni utilisation d'un toolkit 2D puisque dans les 2 cas, le client peut écrire dans son buffer lui-même et envoyer le résultat par mémoire partagée(Qt raster) ou buffer vidéo (DRI2), non?
Après le compositing est sérialisé, mais bon c'est aussi le cas pour Weston.