Et la marmotte??
Tu pourrais envisager d'avoir un serveur X local au client, qui dessine le résultat dans un buffer puis envoit le delta du buffer "à la Wayland compressé" au serveur d'affichage, mais une fois que tu as créer le buffer qui contient le résultat des instructions de dessins (Wayland), tu ne peux plus revenir en arrière et retrouver les instructions de dessin.
Pour le reste il est vrai que les copies de VRAM --> RAM et RAM --> VRAM additionnelle de Wayland doivent être assez courte, mais n'oublie pas de rajouter l'étape de compression (VRAM --> VRAM) sur le client et de décompression sur le serveur (VRAM --> VRAM) pour avoir un truc avec une bande passante acceptable (spécialement en haute définition).
Ça serait intéressante à tester, je sais qu'il y a une backend RDP pour Wayland mais je n'ai jamais vu de vidéo sur Youtube sur le sujet, c'est curieux et je ne suis donc pas sûr que ça marche vraiment..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 0.
Et la marmotte??
Tu pourrais envisager d'avoir un serveur X local au client, qui dessine le résultat dans un buffer puis envoit le delta du buffer "à la Wayland compressé" au serveur d'affichage, mais une fois que tu as créer le buffer qui contient le résultat des instructions de dessins (Wayland), tu ne peux plus revenir en arrière et retrouver les instructions de dessin.
Pour le reste il est vrai que les copies de VRAM --> RAM et RAM --> VRAM additionnelle de Wayland doivent être assez courte, mais n'oublie pas de rajouter l'étape de compression (VRAM --> VRAM) sur le client et de décompression sur le serveur (VRAM --> VRAM) pour avoir un truc avec une bande passante acceptable (spécialement en haute définition).
Ça serait intéressante à tester, je sais qu'il y a une backend RDP pour Wayland mais je n'ai jamais vu de vidéo sur Youtube sur le sujet, c'est curieux et je ne suis donc pas sûr que ça marche vraiment..