Ça y est, je crois que je vois l'un des malentendus: tu parles des animations du compositeur lui-même ("le positionnement d'une fenêtre"), je parle des animations dessinées par l'application dans le contenu de la fenêtre ("la geometrie dessinée dans la fenêtre").
Ok, donc on parlait bien de la meme chose, juste ta phrase etait un peu confuse pour moi, car quand on parle de geometrie, on parle generalement de la geometrie de la fenetre.
Si tu relis ce que j'écris sur la qualité d'animation, ce n'est pas nécessairement (peut-être, peut-être pas) quelque-chose que l'on peut mesurer par un quelconque procédé logiciel. A priori, cela se mesure avec une camera qui filme physiquement l'écran a au moins 60 images par seconde. C'est réellement comme ca que l'on fait dans l'industrie quand on tient vraiment a garantir la qualite réelle d'animation, par exemple les constructeurs d'appareils mobiles ont généralement recours a cette technique. Bien entendu, c'est très coûteux.
En fait, ce genre d'appareil n'est pas necessaire. Tu peux juste mesurer a l'aide d'un timestamp general au systeme quand tu recois un input et quand tu pousses un buffer avec le changement resultant de cet input a l'ecran. Avec un peu de bidouillage dans le protocol wayland et dans le toolkit de l'application, tu peux assez facilement propager ce timestamp de l'input au buffer d'output pour collecter ces informations. En correlant ces informations avec la vsync, tu pourras facilement voire lorsque tu perds des frames.
L'utilisation principal des cameras hautes vitesse que l'on (Samsung) a, c'est pour essayer de "voir" exactement ce que contient une frame avec un glitch graphique (Generalement du a un bug de driver). Pouvoir verifier les pixels a la sortie de l'ecran frame apres frame. On les utilise aussi lorsqu'on a des problemes d'input qui envoie en fait l'information trop tardivement. Mais a part un probleme reellement lie aux drivers, c'est rarement utilise, car franchement pas pratique comme outil d'experimentation et sans valeur ajoute pour la majorite des cas.
Par contre ce qui est amusant, c'est que apres avoir travaille suffisament longtemps dans ce domaine, tes propres yeux savent "sentir" un glitch, un lag, un frame drop. Tu peux meme avoir une estimation du framerate juste avec tes yeux et estimer le lag d'une application en nombre de frame. C'est, je trouve, plus dur de venir avec un chiffre correct pour l'estimation du lag au juge, mais definitivement tu le sens quand ce n'est pas bon.
[^] # Re: Petite erreur
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 2.
Ok, donc on parlait bien de la meme chose, juste ta phrase etait un peu confuse pour moi, car quand on parle de geometrie, on parle generalement de la geometrie de la fenetre.
En fait, ce genre d'appareil n'est pas necessaire. Tu peux juste mesurer a l'aide d'un timestamp general au systeme quand tu recois un input et quand tu pousses un buffer avec le changement resultant de cet input a l'ecran. Avec un peu de bidouillage dans le protocol wayland et dans le toolkit de l'application, tu peux assez facilement propager ce timestamp de l'input au buffer d'output pour collecter ces informations. En correlant ces informations avec la vsync, tu pourras facilement voire lorsque tu perds des frames.
L'utilisation principal des cameras hautes vitesse que l'on (Samsung) a, c'est pour essayer de "voir" exactement ce que contient une frame avec un glitch graphique (Generalement du a un bug de driver). Pouvoir verifier les pixels a la sortie de l'ecran frame apres frame. On les utilise aussi lorsqu'on a des problemes d'input qui envoie en fait l'information trop tardivement. Mais a part un probleme reellement lie aux drivers, c'est rarement utilise, car franchement pas pratique comme outil d'experimentation et sans valeur ajoute pour la majorite des cas.
Par contre ce qui est amusant, c'est que apres avoir travaille suffisament longtemps dans ce domaine, tes propres yeux savent "sentir" un glitch, un lag, un frame drop. Tu peux meme avoir une estimation du framerate juste avec tes yeux et estimer le lag d'une application en nombre de frame. C'est, je trouve, plus dur de venir avec un chiffre correct pour l'estimation du lag au juge, mais definitivement tu le sens quand ce n'est pas bon.