Remote Desktop

Signaler
Messages postés
23
Date d'inscription
samedi 19 avril 2008
Statut
Membre
Dernière intervention
1 février 2014
-
 akablood -
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/100042-remote-desktop

comment on lence ;(
quelqu'un peut m'aider
Messages postés
23
Date d'inscription
samedi 19 avril 2008
Statut
Membre
Dernière intervention
1 février 2014

Effectivement mon remote desktop n'a pas de très bonne performance côté rafraîchissement, pour amélioré cela j'envois donc uniquement les pixels qui ont changé par rapport aux précédentes capture.. mais ce n'est pas suffisant.

Je sais pas si envoyer une capture entière compressé en ZIP soit la meilleur solution, il faut essayer pour voir.. Mais j'ai peur que le temps d'exécution de
l'algo de compression ralentisse les perf de rafraîchissement (compression côté serveur et décompression côté client).
De plus, le format bitmap est a proscrire car trop volumineux, il faut donc enregistrer en jpg et donc encore un algo avec un certain temps d'exécution..
Et pour finir, dans mon programme tt se passe en mémoire, avec ton idée il faut écrire sur le disque dur (côté serveur et client) et donc peut être encore un temps supplémentaire a ajouter et qui aura un impact sur les perf de rafraîchissement.
Tu peux essayer d'adapter ton idée et voir si les perf sont meilleur que celle de mon prog !

concernant UDP, ce protocole est beaucoup utilisé dans des applications qui transmettent des données type audio, video, .. (voix sur IP par exemple),
et pour la bonne raison qu'il est plus rapide que TCP car il n'y a pas de mécanisme de contrôle, et il me semble aussi que le trafique UDP et prioritaire
sur le réseau par rapport a TCP.
Dans mon programme la perte d'un paquet n'est pas dramatique et l'ordre d'arrivée des paquet n'a aucune importance, si tu regarde la structure qui est envoyé il y a un ensemble de pixels et les coordonnée pour chacun d'entre eux.
Messages postés
259
Date d'inscription
samedi 3 janvier 2004
Statut
Membre
Dernière intervention
4 juillet 2021
4 >
Messages postés
23
Date d'inscription
samedi 19 avril 2008
Statut
Membre
Dernière intervention
1 février 2014

Quand j'aurais le temps je ferais des tests. En fait, pas besoin d'accéder au disque dur, suffit de faire le travail de compression en mémoire ; QT permet de travailler avec des fichiers en mémoire et non présent physiquement. Pour la compression ZIP, je crois que QT gère nativement le PNG, il s'agît ni plus ni moins qu'un BMP (Bitmap) mais compressé dans un ZIP, le fichier est potentiellement plus lourd que le JPEG mais l'agorithme de compression et décompression est beaucoup plus rapide, tout comme le traitement de l'image vu que tu as en résultat un simple bitmap (ce qui est le format le plus simple et rapide à lire malgré sa grande taille).

A voir si juste cela suffit à améliorer les performances ; on peut ensuite se tourner vers l'analyse, en effet une fois décompressé et le fait que tu n'as plus que des pixels (QPixmap gère ça très bien si j'ai bonne mémoire), suffit de mettre en relation l'ancienne image et la nouvelle pour en ressortir les pixels qui changent ; tu met alors juste à jour ton QPixmap.

Une autre possibilité c'est simplement la transmission des pixels, en gros côté serveur tu as détecté via une différence entre deux QPixmap, ce qui a changé, et tu transmets (d'où l'exemple du ZIP pour réduire la taille), les pixels qui changent. A l'arrivée, après décompression (si tu compresses), tu te retrouves juste à mettre à jour QPixmap.


Mais au niveau des performances, il faut savoir si c'est le serveur qui met trop de temps ou si c'est le client qui met trop de temps pour traiter les données reçues. Si c'est le client, avec une des mes idées je pense que tu peux sérieusement réduire le temps de traitement ; maintenant si c'est le serveur, c'est plus délicat et il faut faire un bon debug pour trouver la provenance exacte du soucis.

Sauf que l'ordre d'arrivé des données est importante, car imagine que tu reçois des informations correspondant à une fenêtre ouverte de l'autre côté (sur le serveur). Tu fermes la fenêtre puis en ouvre une autre ; manque de bol tu reçoit en premier l'ouverture de l'autre puis la fermeture de la première. Tu te retrouves donc à passer d'un coup de ta seconde fenêtre à un bureau vide car tu as reçu la fermeture de la première mais pas encore la seconde, qu'elle tu as eu juste avant.

L'UDP est utilisé pour la voix et c'est là le soucis, car souvent tu te retrouves justement avec des mots hachés ou incompréhensible justement.

En passant par de l'UDP, dans un remote desktop tu dois donc faire beaucoup de traitement afin que le paquet 2 reçu avant 1, que le résultat du calcul soit bien la contraction entre 1 et 2, donc soit retarder 2 pour traiter 1 puis 2, soit traiter 2 puis 1 mais attendre d'avoir bien eu les deux avant d'afficher.

Ton problème peut tout à fait venir de là d'ailleurs, ça reste à voir ;)
Messages postés
23
Date d'inscription
samedi 19 avril 2008
Statut
Membre
Dernière intervention
1 février 2014
>
Messages postés
259
Date d'inscription
samedi 3 janvier 2004
Statut
Membre
Dernière intervention
4 juillet 2021

Oui c'est sans doute une bonne solution, il faudrait tester, malheureusement j'ai pas de temps actuellement pour modifier tt ca..
Concernant le transfert voila grosso modo le fonctionnement :
- Server : Il mitraille, il capture l'ensemble des pixels, les renverse et fait une comparaison avec la capture précédente (c'est ces 3 actions qui on une incidence sur le temps, j'ai pas fait de mesure mais je pense que c'est assez rapide), ensuite il envois les pixels qui on changé par bloque de X pixels.
- Client : Le client reçoit les bloques de données, quand il a reçut Y bloques une fonction qui s'exécute en parallèle traite ces données (mise a jour de l'affichage), mais le client continue de recevoir des données en provenance du serveur pour qu'il n'y ai pas d'interruption.

Donc je sais pas trop si c'est le client ou le serveur qui met trop de temps, je dirais le serveur par bon sens mais oui il faudrait faire des tests.
Afficher les 9 commentaires