Il a dit ça oui, mais il ne faut pas l'interpréter comme tu le fait..
Wayland n'induit pas beaucoup de lag car il est "efficace" en local tout comme DRI2, mais il n'est pas magique si un programme est lent a régénérer l'affichage de sa fenêtre, il va y avoir des effets lors du redimensionnement..
Le test a été fait avec Windows7 ( http://thread.gmane.org/gmane.comp.freedesktop.wayland.devel/786 ), mais ça devrait être pareil avec Wayland: le redimensionnement de la fenêtre peut être saccadé si le programme est lent puisque tu attends que le programme ait fini d'afficher la fenêtre avec de montrer la nouvelle fenêtre..
Si tu fait le redimensionnement coté serveur, il n'y a pas de saccade car c'est le serveur qui va de manière autonome générer une nouvelle fenêtre, mais si le client est lent alors le résultat sera moche car par exemple le serveur générera la nouvelle fenêtre en ajoutant des bords a l'ancienne ou en tronquant l'ancienne image: moche mais fluide.
(Moche et fluide) ou (joli et saccadé): choisi ton camp, il n'y a pas d'alternative..
Enfin si il y en a une: utiliser une thread par fenêtre coté client à la BeOS ce qui devrait éviter qu'un programme soit lent à se ré-afficher.
[^] # Re: Comment ça marche ?
Posté par reno . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 4.
Il a dit ça oui, mais il ne faut pas l'interpréter comme tu le fait..
Wayland n'induit pas beaucoup de lag car il est "efficace" en local tout comme DRI2, mais il n'est pas magique si un programme est lent a régénérer l'affichage de sa fenêtre, il va y avoir des effets lors du redimensionnement..
Le test a été fait avec Windows7 ( http://thread.gmane.org/gmane.comp.freedesktop.wayland.devel/786 ), mais ça devrait être pareil avec Wayland: le redimensionnement de la fenêtre peut être saccadé si le programme est lent puisque tu attends que le programme ait fini d'afficher la fenêtre avec de montrer la nouvelle fenêtre..
Si tu fait le redimensionnement coté serveur, il n'y a pas de saccade car c'est le serveur qui va de manière autonome générer une nouvelle fenêtre, mais si le client est lent alors le résultat sera moche car par exemple le serveur générera la nouvelle fenêtre en ajoutant des bords a l'ancienne ou en tronquant l'ancienne image: moche mais fluide.
(Moche et fluide) ou (joli et saccadé): choisi ton camp, il n'y a pas d'alternative..
Enfin si il y en a une: utiliser une thread par fenêtre coté client à la BeOS ce qui devrait éviter qu'un programme soit lent à se ré-afficher.