Non-Fluidité de Cairo

Bonjour,
J'ai remis à jour une application graphique sous cairo. Son code source était écrit en X11. Elle marche très bien sous cairo. Seulement un détail me tracasse: pour animer le graphique, je dois mettre à blanc le dessin avant de dessiner un nouveau. Sous X11, cette technique marche très bien et l'animation est très fluide. Par contre, sous cairo, le passage d'un dessin au suivant provoque un clignotement de l'écran qui fait mal aux yeux.

J'aimerais savoir si quelqu'un parmi vous connaît les instructions de cairo qui permettent d'afficher successivement des pages graphiques sans provoquer ces clignotements très gênants.

Merci à l'avance et cordialement

Comment mets-tu l'écran en blanc?

Il existe un système de clipping sous Cairo. Je ne maîtrise pas encore tout ca mais la solution doit sûrement être de ce côté là.

Effectivement, on ne colorie pas en blanc le fond, c'est absolument misérable au niveau performances parce que cela force un appel aux drivers et au matériel. Pour améliorer les performances, il suffit de ne dessiner que ce qui change d'une image à l'autre, et pas l'intégralité de l'image. C'est à cela que sert le clipping.
Tu as des infos sur les animations avec cairo et pyGTK, cairo, GTK et les theads.

Bonsoir,

Grand merci pour vos renseignements. En combinant les techniques Clipping / Masking et sans passer par fond blanc, le déroulement des images est effectivement plus fluide sous cairo. Cela étant dit, le CPU de la machine est complètement bouffé par le tracé des graphiques sous cairo.
Je vais tenter le multi-threading selon les liens que vous m'avez indiqués.

Cordialement

Bonjour,

le multithreading était juste un exemple, parce que tu ne donnes que peu d'informations sur ce que tu fais. En pratique, je déconseille le multi-thread car cela complique le débogage, à moins que la cible soit un processeur multi-coeur et que tu as une exigence très pointue en termes de performances.

Montre nous plutôt le code de ton expose-event pour voir un peu comment tu dessines, il y a sans doute des choses qui peuvent être optimisées. Ensuite, une des règles d'or de l'optimisation: mesurer avant d'optimiser. Je te conseille donc d'utiliser gprof pour faire des mesures afin de déterminer où ton application passe du temps et ce que tu peux améliorer.

Voilà quelques liens pour apprivoiser gprof, cela se fait rapidement.
http://www.ibm.com/developerworks/li...w04GNUProfiler
http://www.cs.utah.edu/dept/old/texi...gprof_toc.html
http://www.network-theory.co.uk/docs...cintro_80.html

Bonjour,
Mon application est trop volumineuse pour l'expliciter. Sa structure, sans multi-threading, est néanmoins assez proche de celle de l'exemple de multi-threading que vous avez indiqué. Par monitoring, je constate que le tracé des surfaces consomme beaucoup de CPU. Il est vrai que je pourrai sans doute l'optimiser encore mais je ne pense pas que cela puisse aller loin. Selon vous, le multi-threading peut-il apporter un saut significatif en performance ?

Cordialement

Tout dépend. (j'aime bien ce genre de réponse qui ne veut rien dire :mouarf:)

Si le temps perdu se trouve lors d'appel de fonction cairo, c'est à dire lors du dessin, le temps ne sera pas fulgurant, d'autant qu'il va falloir mettre en place un/des mutex sur la surface à dessiner. Ce qui se traduit par des attentes, ce qui n'est pas le but.

Pour gagner du temps bien souvent il faut reprendre la philosophie même du soft. Par exemple dans le callback attaché au signal "expose-event" on dessine toute la surface. C'est une erreur. Il vaut mieux dessiner une surface en dehors du callback. Dans le callback on ne fait qu'afficher cette surface, sans aucun calcul. (cet exemple n'est pas une règle inscrite dans le marbre, je précise ;)).

Tout ceci pour dire qu'il faut parfois prendre un peu de recul, si on peu dire...