EFL 1.7.9 et 1.8.2

Les EFL 1.7.9 et 1.8.2 sont sorties et apportent leur lot de corrections de bug et d’améliorations. Pour la version 1.8.2, les ajouts et améliorations principaux sont les suivants :

  • evil : correction de la compilation sous Windows >= Vista
  • eina : augmente la taille d’une table de hashage
  • evas : amélioration de l’accélération pour le clip
  • evas : supprime des rendus inutiles et corrige des erreurs trouvées avec Expedite
  • evas : correction de la compilation du loader PSD pour Solaris
  • evas : correction du rendu
  • evas : amélioration du moteur Wayland
  • ecore : correction de la documentation de l’intégration de glib
  • ecore-evas : corrige le redimensionnement des fenêtre Elementary quand Wayland est utilisé
  • ecore-evas : ajout d’un callback pour l’aspect ratio
  • efreet : corrige un bug de récursivité
  • efreet : protège efreetd d’une récursivité trop importante

Les ajouts et améliorations de la version 1.8 par rapport à la version 1.7.9 se trouvent ici. Comme d’habitude, elles peuvent être téléchargées sur la page officielle. L’annonce officielle se trouve ici.

flattr this!

Les EFL et XCB

Depuis quelque jours, Devilhorns commite sur le SVN du code concernant XCB. Qu’est ce que XCB, à quoi ça sert, quel est le gain pour les EFL d’utiliser XCB ?

D’apres le site officiel :
« The X protocol C-language Binding (XCB) is a replacement for Xlib featuring a small footprint, latency hiding, direct access to the protocol, improved threading support, and extensibility. »

Que l’on pourrait traduire par : XCB est un remplaçant de Xlib, proposant une faible empreinte mémoire, une latence cachée, un accès direct au protocole X, un support des files d’exécution amélioré, et de l’extensibilité.
Les avantages :

  • Gain en mémoire lors de l’exécution (voir plus bas)
  • XCB entièrement thread safe
  • Réactivité d’un gestionnaire de fenêtres
  • Gain de vitesse (certe faible) pour un démarrage de programme par rapport à Xlib en local, mais gain énorme quand l’application est lancée dans un tunnel ssh (~1s pour XCB, ~6s pour Xlib) lorsque l’application est correctement écrite (évidemment)

Regardons comment activer tout ça dans les EFL.
Devilhorns n’est pas parti de 0, puisqu’il a reprit le code de vtorri. On retrouve XCB dans evas et ecore.
Nous devons donc compiler ces deux librairies avec le support de xcb :
Pour evas :

./configure --prefix=/opt/e17 --enable-software-xcb

Ce qui nous donne comme résultat :

Engines:
Software Memory Buffer.....: yes
Software X11...............: yes (Xlib: no) (XCB: yes)

et pour ecore :

./configure --prefix=/opt/e17 --enable-ecore-x-xcb

ce qui nous donne :

Ecore_X (XCB backend)........: yes
....
Ecore_Evas...................: yes
Software Memory Buffer.....: yes
Software X11...............: yes (Xlib=no) (XCB=yes)

Comparons les résultats avant et après compilation :
La mémoire utilisée par E17 avant de compiler le support XCB est (RES – SHR) => 39M – 8536 = 30.4MB
Après avoir compilé le support XCB : 21M – 9952 = 11.048MB !

La mémoire utilisée est presque divisée par 3 ! Et e17 est toujours utilisable.
Juste un petit bémol, Dans le cas où vous voudriez activer XCB, sachez que vous ne pourrez plus utiliser le moteur OpenGL de Evas, en raison d’une support opengl non fini dans XCB. Il en est de même pour le backend opengl/es de evas, bien que pour cette partie ça ne soit qu’une question de temps avant que devilhorns ajoute ce support dans ecore et evas.

Notez également que le composite logiciel reste opérationnel avec XCB.

flattr this!