Le double buffering, c'est juste sur le contenu du buffer graphique. C'est principalement utilise pour eviter les problemes de synchronisation avec l'ecran. L'idee, c'est que tu peux travailler dans un buffer pendant que le deuxieme buffer est pousse a l'ecran.
Theoriquement on devrait pouvoir se passer completement de ce buffer supplementaire qui impact la latence pour afficher ce qui ce doit au plus pres du moment ou le contenu va arriver a l'ecran. Tu as toujours au moins une latence de 16ms a 60Hz, mais ca peut varier car il n'y a pas de synchronisation explicite dans la chaine de rendu et du cout les applications travaillent souvent avec en fait 3 buffers. Pour une petite introduction sur le sujet: https://github.com/ishitatsuyuki/LatencyFleX . Aucun toolkit a ma connaissance n'en est la pour l'instant.
Maintenant, pour Wayland et dans certain cas sous X11, tu peux te retrouver a travailler dans le buffer que tu avais presente a l'ecran il y a 2 frames. Du coup, tu peux, si tu as une idee des changements qui ont eu lieu, faire un delta et uniquement toucher les morceaux du buffer qui ont change. Pour faire ce delta, tu ne travaille pas au niveau des pixels, cela serait trop couteux, mais au niveau des boundings box des primitives graphiques qui composent la scene que tu dois rendre. En regardant quel bounding box a visiblement change depuis les 2 ou 3 dernieres frame, tu peux construire un "masque" des zones a redessiner. Mais cela s'applique uniquement a Linux, les autres ecosystemes n'ont pas cette fonctionnalite et ne permettent pas de connaitre l'age d'un buffer. Du cout, peu de toolkit graphique implemente cette optimisation. Cela n'est peut etre plus vrai avec Vulkan, mais je n'en suis pas certain.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Le double buffering, c'est juste sur le contenu du buffer graphique. C'est principalement utilise pour eviter les problemes de synchronisation avec l'ecran. L'idee, c'est que tu peux travailler dans un buffer pendant que le deuxieme buffer est pousse a l'ecran.
Theoriquement on devrait pouvoir se passer completement de ce buffer supplementaire qui impact la latence pour afficher ce qui ce doit au plus pres du moment ou le contenu va arriver a l'ecran. Tu as toujours au moins une latence de 16ms a 60Hz, mais ca peut varier car il n'y a pas de synchronisation explicite dans la chaine de rendu et du cout les applications travaillent souvent avec en fait 3 buffers. Pour une petite introduction sur le sujet: https://github.com/ishitatsuyuki/LatencyFleX . Aucun toolkit a ma connaissance n'en est la pour l'instant.
Maintenant, pour Wayland et dans certain cas sous X11, tu peux te retrouver a travailler dans le buffer que tu avais presente a l'ecran il y a 2 frames. Du coup, tu peux, si tu as une idee des changements qui ont eu lieu, faire un delta et uniquement toucher les morceaux du buffer qui ont change. Pour faire ce delta, tu ne travaille pas au niveau des pixels, cela serait trop couteux, mais au niveau des boundings box des primitives graphiques qui composent la scene que tu dois rendre. En regardant quel bounding box a visiblement change depuis les 2 ou 3 dernieres frame, tu peux construire un "masque" des zones a redessiner. Mais cela s'applique uniquement a Linux, les autres ecosystemes n'ont pas cette fonctionnalite et ne permettent pas de connaitre l'age d'un buffer. Du cout, peu de toolkit graphique implemente cette optimisation. Cela n'est peut etre plus vrai avec Vulkan, mais je n'en suis pas certain.