Pourquoi pas ? Où est le problème à ce qu'une application crée son propre buffer graphique et dessine sa fenêtre tout seule comme une grande puis passe le pointer au Compositor ?
L'un des soucis majeurs de l'allocation côté serveur c'est le nombre de roundtrips inutiles client-serveur vu que l'application doit sans cesse demander un nouveau buffer de telle taille au serveur. Je te laisse imaginer le nombre d'IPCs à chaque redimensionnement de fenêtre en plus du fait que le client doit toujours attendre la réponse du server avant de pouvoir dessiner. Un problème autre que la lenteur c'est que X ne peut jamais savoir quelle taille la fenêtre du client sera à t+1, et devra attendre la requête du client pour le savoir, et le temps que le client obtienne son buffer il est souvent déjà invalidé. C'est la source des soucis de corruption/clignotement dans les fenêtres lors de redimensionnements par exemple...
En résumé ça fait 30 ans que les devs X se pètent les dents là dessus; Windows et OSX ayant définitivement enterré l'idée y'a très longtemps aussi. Ça avait peut être du sens quand X se chargeait lui-même de dessiner les fenêtres, mais maintenant à part les rares applis en Motif et xterm toutes les applis/toolkits font leur rendu localement. X est aussi sur cette voie vu que DRI2 autorise déjà partiellement le client-side allocation. DRI3000 va plus loin dans ce sens en étant full client-side ( http://keithp.com/blogs/dri3k_first_steps/ ).
Après, le client-side à ses défauts aussi comme un moindre contrôle sur les buffers (genre on peut plus désallouer aussi facilement un buffer pour une appli qui est minimisée pour libérer de la mémoire) et donc une consommation en RAM plus conséquente, ce qui peut être une contrainte sur les mobiles/tablettes. C'est la justification de Canonical en tout cas, bien que à mon avis fallacieuse vu que Wayland ne force pas l'allocation client (y'avait même un Weston expérimental en server-side), et que la quantité de RAM des mobiles ne cesse d'augmenter...
[^] # Re: Waylands et Mir ?
Posté par Scias . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 6.
Pourquoi pas ? Où est le problème à ce qu'une application crée son propre buffer graphique et dessine sa fenêtre tout seule comme une grande puis passe le pointer au Compositor ?
L'un des soucis majeurs de l'allocation côté serveur c'est le nombre de roundtrips inutiles client-serveur vu que l'application doit sans cesse demander un nouveau buffer de telle taille au serveur. Je te laisse imaginer le nombre d'IPCs à chaque redimensionnement de fenêtre en plus du fait que le client doit toujours attendre la réponse du server avant de pouvoir dessiner. Un problème autre que la lenteur c'est que X ne peut jamais savoir quelle taille la fenêtre du client sera à t+1, et devra attendre la requête du client pour le savoir, et le temps que le client obtienne son buffer il est souvent déjà invalidé. C'est la source des soucis de corruption/clignotement dans les fenêtres lors de redimensionnements par exemple...
En résumé ça fait 30 ans que les devs X se pètent les dents là dessus; Windows et OSX ayant définitivement enterré l'idée y'a très longtemps aussi. Ça avait peut être du sens quand X se chargeait lui-même de dessiner les fenêtres, mais maintenant à part les rares applis en Motif et xterm toutes les applis/toolkits font leur rendu localement. X est aussi sur cette voie vu que DRI2 autorise déjà partiellement le client-side allocation. DRI3000 va plus loin dans ce sens en étant full client-side ( http://keithp.com/blogs/dri3k_first_steps/ ).
Après, le client-side à ses défauts aussi comme un moindre contrôle sur les buffers (genre on peut plus désallouer aussi facilement un buffer pour une appli qui est minimisée pour libérer de la mémoire) et donc une consommation en RAM plus conséquente, ce qui peut être une contrainte sur les mobiles/tablettes. C'est la justification de Canonical en tout cas, bien que à mon avis fallacieuse vu que Wayland ne force pas l'allocation client (y'avait même un Weston expérimental en server-side), et que la quantité de RAM des mobiles ne cesse d'augmenter...
Maintenant Mir heureusement fait les choses un peu différemment de X et évite quelques allers-retours inutiles ( http://blog.cooperteam.net/2013/03/server-allocated-buffers-in-mir.html ), mais techniquement il y aura toujours un avantage au client-side niveau vitesse en tout cas.