Je te conseille la lecture complete de cette page : http://trac.enlightenment.org/e/wiki/EFLOverview qui t'expliquera toutes les differences entre un toolkit moderne et des toolkits plus ancien. Elle est longue et dense, mais il y a tellement de concept different a presenter qu'il n'y a pas le choix.
Et oui, il y a vraiment des differences fondamentales dans la maniere de gerer le pipeline graphique avec les EFLs. Oui, chaque composant est etudie pour etre le plus efficace possible.
Tu as donc regarde la main loop, c'est a dire la bibliotheque Ecore, tu as donc note la presence d'idler (enterer, exiter), d'animator et de poller. Chacun de ces types de timer ont leur utilite. Ainsi l'idler enterer sert a declencher le rendu du canvas, car c'est a ce moment la que Ecore sait qu'il n'a plus rien a faire et donc que le canvas est dans un etat stable et donc qu'on peut faire le rendu. Il n'y a donc pas de rendu intermediaire, on ne voit pas la fenetre se construire. Les animators eux sont tous execute de maniere synchronise a la vitesse des fps du systeme. Cela permet d'avoir toutes ses animations de maniere synchro. Cela peut paraitre trivial dit comme ca, mais certain toolkit ont quand meme des animators qui ne sont pas synchronise, ce qui fait qu'au lieu d'avoir une application qui doit fonctionne a 60fps, tu as une application qui tente de tourner a n * 60fps ou n est le nombre d'animator. Je te laisse imaginer les problemes que cela pose... Enfin les pollers sont des timer imprecis qui s'on appele lorsque d'autre timer ou evenement reveille le systeme. Cela evite de reveiller le systeme pour savoir l'etat de la batterie par exemple et profite plutot que le systeme est reveille pour faire cette tache.
Tout cela concour a ce que la mainloop propose de nombreux mecanismes pour simplifier l'ecriture d'une application optimale et consommant effectivement moins de batterie. Mais clairement la main loop est une tache trivialle et ce n'est pas la que se passe les optimisations qui offrent le plus de gain. Evas est veritablement le coeur du systeme et de son design vient reellement la difference par rapport aux autres toolkit. Comme explique plus en detail sur le lien que j'ai mis en haut de cette page, le fait que l'on manipule des objets sur le canvas et non qu'on peigne dessus directement offre d'enorme facilite d'optimisation qu'aucun toolkit aujourd'hui ne peut mettre en place. C'est une difference architecturale majeur. Si tu ne me crois pas, je vais te referer au blog QT de Zack Rusin qui decrit comment il pense implementer ca dans QML et Webkit: http://zrusin.blogspot.com/2010/11/2d-musings.html .
[^] # Re: des possibilités graphiques hors du commun.
Posté par cedric . En réponse à la dépêche Conférence Parinux : les Enlightenment Foundation Libraries (EFL). Évalué à 9.
Je te conseille la lecture complete de cette page : http://trac.enlightenment.org/e/wiki/EFLOverview qui t'expliquera toutes les differences entre un toolkit moderne et des toolkits plus ancien. Elle est longue et dense, mais il y a tellement de concept different a presenter qu'il n'y a pas le choix.
Et oui, il y a vraiment des differences fondamentales dans la maniere de gerer le pipeline graphique avec les EFLs. Oui, chaque composant est etudie pour etre le plus efficace possible.
Tu as donc regarde la main loop, c'est a dire la bibliotheque Ecore, tu as donc note la presence d'idler (enterer, exiter), d'animator et de poller. Chacun de ces types de timer ont leur utilite. Ainsi l'idler enterer sert a declencher le rendu du canvas, car c'est a ce moment la que Ecore sait qu'il n'a plus rien a faire et donc que le canvas est dans un etat stable et donc qu'on peut faire le rendu. Il n'y a donc pas de rendu intermediaire, on ne voit pas la fenetre se construire. Les animators eux sont tous execute de maniere synchronise a la vitesse des fps du systeme. Cela permet d'avoir toutes ses animations de maniere synchro. Cela peut paraitre trivial dit comme ca, mais certain toolkit ont quand meme des animators qui ne sont pas synchronise, ce qui fait qu'au lieu d'avoir une application qui doit fonctionne a 60fps, tu as une application qui tente de tourner a n * 60fps ou n est le nombre d'animator. Je te laisse imaginer les problemes que cela pose... Enfin les pollers sont des timer imprecis qui s'on appele lorsque d'autre timer ou evenement reveille le systeme. Cela evite de reveiller le systeme pour savoir l'etat de la batterie par exemple et profite plutot que le systeme est reveille pour faire cette tache.
Tout cela concour a ce que la mainloop propose de nombreux mecanismes pour simplifier l'ecriture d'une application optimale et consommant effectivement moins de batterie. Mais clairement la main loop est une tache trivialle et ce n'est pas la que se passe les optimisations qui offrent le plus de gain. Evas est veritablement le coeur du systeme et de son design vient reellement la difference par rapport aux autres toolkit. Comme explique plus en detail sur le lien que j'ai mis en haut de cette page, le fait que l'on manipule des objets sur le canvas et non qu'on peigne dessus directement offre d'enorme facilite d'optimisation qu'aucun toolkit aujourd'hui ne peut mettre en place. C'est une difference architecturale majeur. Si tu ne me crois pas, je vais te referer au blog QT de Zack Rusin qui decrit comment il pense implementer ca dans QML et Webkit: http://zrusin.blogspot.com/2010/11/2d-musings.html .