Je veux pas casser tes reves, mais esperer qu'un nouveau driver pour wayland qui sera plus performant et moins bugge que l'actuel arrive sur ta machine me parait assez optimiste :-)
Sinon un pentium 4, c'est pas trop ce que j'appel une vieille machine. En comparaison a un Eee 701, je pense que ton Pentium 4 doit etre largement plus puissant. Perso, j'utilise Enlightenment 17 sur une Arch et j'ai un boot operationnel au bout de 30s. J'utilise regulierement xchat, chrome, ephoto, eyelight et amsn dessus. Amsn etant le plus gros consomateur de ressource du lot !
Bien entendu, pas la peine d'espere faire tourner OpenOffice, ni une Ubuntu avec KDE ou GNOME (J'ai essaye juste pour etre sur). Et de ces experiences, la conclusion c'est clairemetn que le probleme est applicatif et non plus bas. Un bon toolkit qui utilise bien le hard disponible reussi a faire de mon eee une machine tout a fait utilisable...
Quand le probleme n'est pas correctement identifie, le changement n'apportera rien voir meme ca va casser les trucs qui marchent...
Le changement en soit n'est pas bien ou mal, mais d'abord il faut identifier ce qui doit etre changer et aujourd'hui, vu la catastrophe que represente des toolkits comme QT ou GTK. C'est pas en gagnant maximum 5% de perfs (C'est la difference de perf entre une appli de benchmark entre le frame buffer et X), que tu vas revolutionner la fluidite et l'interactivite de ton desktop.
Faut commencer par designer des pipeline graphiques correct, ensuite les optimiser. Enfin refaire une photo de l'ensemble et peut etre qu'arriver a ce point la, on se dira que gagner 5% de plus ca vaudra le coup. Mais actuellement, il y a des optimisations a faire cote toolkit qui donne facilement des perfs en *2 ou *3 (Oui, 200 ou 300%). Donc c'est la qu'il faut mettre de l'energie et pas sur un truc marginal !
Euh, je crois qu'il y a un truc que tu as loupe. Avec Wayland, tu es oblige de passer par un composite manager, avec X ce n'est pas le cas. Donc pour etre fairplay, il faut comparer X + composite manager avec Wayland + composite manager.
La synchro avec la vsync et ce genre de chose, c'est le boulot du composite manager, et mon composite manager X, il le fait tres bien quand je le lui demande.
Le deuxieme point, la lenteur des applications et du temps a se rafraichir, tout d'abord avec un composite manager, tu peux laisser tout le temps que tu veux a l'application pour se reafficher, vu que tu as le contenu de la precedente frame pour bosser... Super solution, au lieu de faire en sorte qu'une appli aille vite et ne bloque jamais l'affichage...
Pareil XCB, c'est une bonne evolution, mais ca ne changera rien a la majorite des applications. Le seul qui peut y gagner avec xcb, c'est ton window manager, qui a moins d'aller/retour a faire pour creer des fenetres. Pour une application, ca ne changera juste rien.
Le probleme n'est pas dans X, mais dans des toolkits graphiques mal ecrit et qui ne savent pas faire un pipeline de rendu 2D correct. Avant de tapper sur les drivers/X, il faut commencer par coder correctement les toolkits. Et il faut aller prendre l'inspiration chez des gens qui font des trucs perfomants... les jeux. Copier le pipeline de rendu d'un jeu moderne, c'est ca qui donnera des perfs a vos applications. Switcher a Wayland ne changera rien.
Pour rassurer tout le monde, je pense que les travaux commence enfin dans QT avec l'utilisation de techno comme QML qui permette de completement abstraire un SceneGraphe permettra enfin de se diriger pour ce toolkit vers des performances honorable. Je suis par contre plus dubitatif pour GTK qui ne me semble plus avoir ce genre de projet a l'ordre du jour. Enfin si vous voulez voir la difference, il y a les EFL et E17 pour avoir une architecture efficace graphiquement. La preuve, il est possible de faire tourner un composite manager en software sur un EEE 701. Comme quoi, le probleme a ete mal identifie.
Et sinon le rapport entre synchrone et multicoeur, faudra aussi que tu m'expliques ? Parce que la technique pour tirer au mieux parti de ton CPU multicoeur, c'est qu'une fois toutes les ressources de la frame a dessine locke, tu declenches le rendu dans un thread separe de maniere a pouvoir retourner le plus rapidement possible a la logique de ton appli.
Si l'etat propose un service non rentable, ca veut dire que ceux sont tes impots qui le subventionne. Tu payes ainsi pour l'entretien et la construction de tout le reseau routier par exemple. Je ne vois pas l'interet de payer pour un reseau mobile qui au final aura la meme puissance emise puisqu'elle est optimise localement par les operateurs local pour convenir aux nombres d'utilisateurs statistiquement attendu a cette endroit la. Car oui, les operateurs payant aux nombres de slot actif par antenne, ils adaptent leur reseau en permanence au minimum possible.
En fait, en le nationalisant, tu aurais surement l'effet inverse de celui recherche, plus d'optimisation de la couverture pour reduire les couts, donc augmentation de la puissance globale emise.
On parle de Paris la., avec un reseau 3G pas loin de la saturation avec tous ces iphones ou autres android. Ce n'est pas en mutualisant les antennes que tu augmentent le nombre de connexion par antenne. Il faut plus de spectre et plus d'emission pour gerer plus de requetes de plus de clients. Et note concernant les capacites d'une cellule, en HSDPA, tu as du 3.5Mbps de dispo a se partager par tout le monde. Pour l'ordre de grandeur, la TV ADSL, c'est en general aussi 3.5Mbps, mais par client.
Donc soit on laisse tomber l'evolution du mobile soit on met les antennes necessaire.
Oh, le beau troll ! Ils ont decide de passe a QT parce que Nokia a racheter Trolltech et qu'ils ont maintenant les competences en interne pour avoir un toolkit qui correspond peut-etre mieux a leur besoin.
Et comme ceux sont deux societes, Intel et Nokia, qui sont derriere Meego, ils ne vont pas reecrire ce qui marche/existe deja. Ils s'attaquent d'abord a l'enorme TODO pour rendre utilisable Meego sur un telephone.
En meme temps, ca n'a rien de surprenant. Orange reve de pouvoir refaire le coup du minitel, et la, il a affaire a Google et Apple qui ont reussi a le faire. Forcement, il veut les copier !
J'aurais plutot parle de Calaos comme solution libre et avance dans le domaine. En plus pour une fois que c'est francais, joli, libre et que le dev est sympa, je vais pas me priver d'en parler !
On doit pas utiliser le meme Gtk+ ! Mais sincerement XRender est juste mauvais et inutilisable sur tous les drivers majeurs. Un bon moteur soft enterre juste par un facteur plutot aux alentours de 10 les perfs de XRender.
De plus de nos jours, on veut des effets graphiques et l'API de XRender se revele juste inadapte par rapport a l'API OpenGL.
Conclusion, aujourd'hui, soit on fait son moteur soft, soit on fait de l'OpenGL. Mais dans tous les cas on laisse tomber XRender. C'est juste surprenant que GTK ou QT l'utilise encore.
Ce n'est pas uniquement une question de taille de code, mais aussi d'allocation memoire. De maniere generale compare une bibliotheque comme QT avec enormement de feature dans une seule lib ecrite en C++ face aux EFL ou chaque feature est devolue a une seule lib ecrite en C. Ce n'est pas fair play.
Lors des tests, il y a environ 3 ans, aucune libs ne permettaient d'avoir d'emble une solution acceptable sur Freebox HD. QT provoquait quasiment instantaneement un OOM, GTK n'a jamais voulu afficher quoique ce soit meme apres plusieurs minute de 100% de CPU, seuls les EFL ont ete d'accord d'afficher quelque chose au bout de 80s. Les tests sur le meme hardware et sur la meme applications EFL sont aujourd'hui a 6s.
Ce qui m'etonne toujours un peu, c'est que les EFL sont peut etre tres optimise, mais il y a encore beaucoup de chose qui peuvent etre ameliorer. Diminution de la consommation memoire et du temps de construction d'un objet, optimisation du pipeline de rendu pour repartir l'initialisation des ressources graphiques plus efficacement, ...
L'introspection, c'est bien, car ca facilite le boulot des devs pour maintenir a jour leur bindings. Mais ca a un gros default, ca consomme plus de RAM et plus de CPU. Et ce n'est pas marginale, donc ne pas l'oublier quand on utilise ces solutions...
D'apres ce que j'ai suivi sur QML, ceux sont les personnes qui ont essaye de realiser QEdje qui ont participe a la creation de QML. Mais maintenant la phylosophie derriere, il y a pas mal de difference entre QML et Edje.
Edje est concu pour etre sandboxable et propose une vrai separation de la logique applicative du design de l'interface. L'objectif etant de n'avoir qu'a change le theme quand tu changes de terminal (telephone, netbook, tablet, ...).
QML au contraire, permet de quasiment coder toute ton application dedans. Ca lui permet de faire beaucoup plus de chose avec un seul langage, mais cela a un prix. Prix en terme de modularite, de fonctionnalite et de performance.
Sinon pour ce qui est de Edje, et de l'acceleration hardware. Edje utilise le canvas propose par Evas qui va utiliser divers backend parmis le moteur purement soft, directfb, sdl, opengl et opengl-es. Il est vrai que le backend soft est tres performant, et tiens souvent la drage haute au backend gl.
Pour diverse raison, entre autre que le backend soft est plus intelligent en consommant moins de bande passante. OpenGL n'est pas adapte a faire des interfaces 2D, car il force a redessiner tout l'ecran et donc necessite un fillrate plus eleve. Apres lorsqu'on a besoin du CPU principal pour autre chose que l'affichage, ce qui est souvent le cas dans l'embarque, on va bien entendu utiliser les moteurs accelerer par des puces dedies. Donc OpenGL n'est pas la panace absolu qui rendra vos interfaces belles et fluides. Juste une solution qui marche pour ameliorer des fois les choses.
Aujourd'hui, il y a surement bien plus de Linux dans l'embarque que ailleur. Et ca va vraiment plus dans cette direction, smartbook, telephone, homeserver, tablette ...
Toutes ces machines les gens s'attendent a ce qu'elle demarre instantanement. Alors ameliorer le temps de boot et optimiser le systeme, ca interresse beaucoup beaucoup d'utilisateurs, en fait surement la majorite et en plus ceux qui payent !
D'un point de vue pragmatique, le projet qui va surement etre le plus interresse par ce nouvel init, ce sera MeeGo. Donc ca redescendra surement par toutes les distrib qui l'utiliseront.
Juste pour signaler qu'une presentation par Archos au RMLL des possibilites de developpement grace a ce firmware Special Developper Edition est planifie.
Oui, on t'a menti. C'est bien d'utiliser le goto pour gerer les erreurs et les sorties de fonctions aussi. Comme ca, tu as un unique point de sortie dans ta fonction, et tu n'oublies pas de liberer/nettoyer la misere que ta fonction a cree en memoire :-)
Juste comme ca, quand on parle de decodeur hardware, la grande majorite se base aujourd'hui sur des DSP. Les DSP, ca se programment, c'est du soft. Ca se met a jour et ca s'etend. La question est plus de coder un nouveau codec pour tous ces DSP qu'autre chose. Pas vraiment si bloquant que ca.
Pour les encodeurs, c'est different. Aujourd'hui, pour le h264, tu as un encodeur libre et performant absolument excellent: x264. Il te fait du live, ou de l'encodage differe de bien meilleur qualite et efficacement que des encodeurs hard. Si On2 a un encodeur soft du meme niveau de qualite, VP8 prend la main demain aussi vite que h264. Et vu la puissance/cout des serveurs aujourd'hui, il faut etre fou pour parler encore d'encodeur hardware pour autre chose que l'embarque.
Le seul avantage des biocaburant a base d'algues ou de bacterie, c'est que ca ne devrait pas impacter notre source de nourriture. Mais globalement, ca ne permettra pas de continuer a vivre comme nous vivons aujourd'hui. Faut arreter de rever ou de prendre de la drogue.
Euh, il y a moyen de faire du developpement natif sur android ? Parce que si ce n'est pas le cas, il faut reecrire integralement le jeu et maintenir un fork complet et permanent des sources... Pas vraiment l'ideal !
En fait, il parle de compiz, car c'est le nom que tout le monde connait, mais dans la pratique et comme dis dans le ChangeLog et sur l'annonce d'Elive, c'est Ecomorph qui est utilise.
Les EFL, c'est portable. C'est un toolkit au meme titre que GTK ou QT qui te fournit un rendu graphique portable et optimise. Les EFL sont entierement modulaire, et tu as de multiple backend, X11, FrameBuffer, DirectFB, SDL, OpenGL, Cocoa, GDI, DirectX, ... Et j'ai surement du en oublier.
C'est meconnaitre les EFL que de croire que c'est d'elle que viendra le probleme de portabilite :-)
[^] # Re: Fausse polémique ?
Posté par cedric . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 1.
Sinon un pentium 4, c'est pas trop ce que j'appel une vieille machine. En comparaison a un Eee 701, je pense que ton Pentium 4 doit etre largement plus puissant. Perso, j'utilise Enlightenment 17 sur une Arch et j'ai un boot operationnel au bout de 30s. J'utilise regulierement xchat, chrome, ephoto, eyelight et amsn dessus. Amsn etant le plus gros consomateur de ressource du lot !
Bien entendu, pas la peine d'espere faire tourner OpenOffice, ni une Ubuntu avec KDE ou GNOME (J'ai essaye juste pour etre sur). Et de ces experiences, la conclusion c'est clairemetn que le probleme est applicatif et non plus bas. Un bon toolkit qui utilise bien le hard disponible reussi a faire de mon eee une machine tout a fait utilisable...
[^] # Re: Fausse polémique ?
Posté par cedric . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 2.
Le changement en soit n'est pas bien ou mal, mais d'abord il faut identifier ce qui doit etre changer et aujourd'hui, vu la catastrophe que represente des toolkits comme QT ou GTK. C'est pas en gagnant maximum 5% de perfs (C'est la difference de perf entre une appli de benchmark entre le frame buffer et X), que tu vas revolutionner la fluidite et l'interactivite de ton desktop.
Faut commencer par designer des pipeline graphiques correct, ensuite les optimiser. Enfin refaire une photo de l'ensemble et peut etre qu'arriver a ce point la, on se dira que gagner 5% de plus ca vaudra le coup. Mais actuellement, il y a des optimisations a faire cote toolkit qui donne facilement des perfs en *2 ou *3 (Oui, 200 ou 300%). Donc c'est la qu'il faut mettre de l'energie et pas sur un truc marginal !
[^] # Re: Fausse polémique ?
Posté par cedric . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 1.
Sinon un serveur X, ca tourne tres bien sur des machines d'il y a 20 ans. Tu as une machine encore plus vieille ?
[^] # Re: j'approuve
Posté par cedric . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 10.
La synchro avec la vsync et ce genre de chose, c'est le boulot du composite manager, et mon composite manager X, il le fait tres bien quand je le lui demande.
Le deuxieme point, la lenteur des applications et du temps a se rafraichir, tout d'abord avec un composite manager, tu peux laisser tout le temps que tu veux a l'application pour se reafficher, vu que tu as le contenu de la precedente frame pour bosser... Super solution, au lieu de faire en sorte qu'une appli aille vite et ne bloque jamais l'affichage...
Pareil XCB, c'est une bonne evolution, mais ca ne changera rien a la majorite des applications. Le seul qui peut y gagner avec xcb, c'est ton window manager, qui a moins d'aller/retour a faire pour creer des fenetres. Pour une application, ca ne changera juste rien.
Le probleme n'est pas dans X, mais dans des toolkits graphiques mal ecrit et qui ne savent pas faire un pipeline de rendu 2D correct. Avant de tapper sur les drivers/X, il faut commencer par coder correctement les toolkits. Et il faut aller prendre l'inspiration chez des gens qui font des trucs perfomants... les jeux. Copier le pipeline de rendu d'un jeu moderne, c'est ca qui donnera des perfs a vos applications. Switcher a Wayland ne changera rien.
Pour rassurer tout le monde, je pense que les travaux commence enfin dans QT avec l'utilisation de techno comme QML qui permette de completement abstraire un SceneGraphe permettra enfin de se diriger pour ce toolkit vers des performances honorable. Je suis par contre plus dubitatif pour GTK qui ne me semble plus avoir ce genre de projet a l'ordre du jour. Enfin si vous voulez voir la difference, il y a les EFL et E17 pour avoir une architecture efficace graphiquement. La preuve, il est possible de faire tourner un composite manager en software sur un EEE 701. Comme quoi, le probleme a ete mal identifie.
Et sinon le rapport entre synchrone et multicoeur, faudra aussi que tu m'expliques ? Parce que la technique pour tirer au mieux parti de ton CPU multicoeur, c'est qu'une fois toutes les ressources de la frame a dessine locke, tu declenches le rendu dans un thread separe de maniere a pouvoir retourner le plus rapidement possible a la logique de ton appli.
[^] # Re: j'aimerais lire un jour...
Posté par cedric . En réponse à la dépêche Enlightenment Foundation Libraries 1.0.0 Bêta. Évalué à 4.
Donc toute l'equipe d'Enlightenment France se tient disponible et pret a repondre aux questions qu'on pourrait lui poser avec plaisir.
[^] # Re: Trop d'antennes ? Y'a une solution simple...
Posté par cedric . En réponse au journal "Free Mobile : la ville de Paris sous pression pour limiter le nombre d'antennes". Évalué à 2.
En fait, en le nationalisant, tu aurais surement l'effet inverse de celui recherche, plus d'optimisation de la couverture pour reduire les couts, donc augmentation de la puissance globale emise.
[^] # Re: Supposition erronée
Posté par cedric . En réponse au journal "Free Mobile : la ville de Paris sous pression pour limiter le nombre d'antennes". Évalué à 5.
Donc soit on laisse tomber l'evolution du mobile soit on met les antennes necessaire.
[^] # Re: Qt sur Meego, j'ai pas très bien compris.
Posté par cedric . En réponse à la dépêche Sortie de Qt 4.7. Évalué à 1.
Et comme ceux sont deux societes, Intel et Nokia, qui sont derriere Meego, ils ne vont pas reecrire ce qui marche/existe deja. Ils s'attaquent d'abord a l'enorme TODO pour rendre utilisable Meego sur un telephone.
# Minitel 2.0
Posté par cedric . En réponse au journal Orange veut son propre système d'exploitation. Évalué à 3.
[^] # Re: MisterHouse
Posté par cedric . En réponse au journal "Home automation". Évalué à 4.
Alors pour ceux qui veulent voir a quoi ca ressemble :
http://www.dailymotion.com/video/xcx271_calaos-home-gestion-(...)
http://www.dailymotion.com/video/xcx1y4_calaos-home-gestion-(...)
http://www.dailymotion.com/video/xcx3v0_calaos-home-configur(...)
http://www.dailymotion.com/video/xcx1e8_calaos-home-interfac(...)
Sinon pour le code, c'est ici :
http://dev.calaos.fr/trac/browser
Et pour le blog des devs :
http://blog.calaos.fr/
[^] # Re: Re:
Posté par cedric . En réponse au journal En finir avec la lourdeur de KDE - version simple. Évalué à 1.
De plus de nos jours, on veut des effets graphiques et l'API de XRender se revele juste inadapte par rapport a l'API OpenGL.
Conclusion, aujourd'hui, soit on fait son moteur soft, soit on fait de l'OpenGL. Mais dans tous les cas on laisse tomber XRender. C'est juste surprenant que GTK ou QT l'utilise encore.
[^] # Re: optimisation?
Posté par cedric . En réponse à la dépêche Enlightenment Foundation Libraries 1.0.0 Alpha. Évalué à 9.
Lors des tests, il y a environ 3 ans, aucune libs ne permettaient d'avoir d'emble une solution acceptable sur Freebox HD. QT provoquait quasiment instantaneement un OOM, GTK n'a jamais voulu afficher quoique ce soit meme apres plusieurs minute de 100% de CPU, seuls les EFL ont ete d'accord d'afficher quelque chose au bout de 80s. Les tests sur le meme hardware et sur la meme applications EFL sont aujourd'hui a 6s.
Ce qui m'etonne toujours un peu, c'est que les EFL sont peut etre tres optimise, mais il y a encore beaucoup de chose qui peuvent etre ameliorer. Diminution de la consommation memoire et du temps de construction d'un objet, optimisation du pipeline de rendu pour repartir l'initialisation des ressources graphiques plus efficacement, ...
# Petite introspection sur l'introspection
Posté par cedric . En réponse au journal Gobject Introspection, Parrot, Mono, JVM etc.. Évalué à 6.
[^] # Re: Edje
Posté par cedric . En réponse au journal QML: le futur des interfaces graphiques. Évalué à 4.
Edje est concu pour etre sandboxable et propose une vrai separation de la logique applicative du design de l'interface. L'objectif etant de n'avoir qu'a change le theme quand tu changes de terminal (telephone, netbook, tablet, ...).
QML au contraire, permet de quasiment coder toute ton application dedans. Ca lui permet de faire beaucoup plus de chose avec un seul langage, mais cela a un prix. Prix en terme de modularite, de fonctionnalite et de performance.
Sinon pour ce qui est de Edje, et de l'acceleration hardware. Edje utilise le canvas propose par Evas qui va utiliser divers backend parmis le moteur purement soft, directfb, sdl, opengl et opengl-es. Il est vrai que le backend soft est tres performant, et tiens souvent la drage haute au backend gl.
Pour diverse raison, entre autre que le backend soft est plus intelligent en consommant moins de bande passante. OpenGL n'est pas adapte a faire des interfaces 2D, car il force a redessiner tout l'ecran et donc necessite un fillrate plus eleve. Apres lorsqu'on a besoin du CPU principal pour autre chose que l'affichage, ce qui est souvent le cas dans l'embarque, on va bien entendu utiliser les moteurs accelerer par des puces dedies. Donc OpenGL n'est pas la panace absolu qui rendra vos interfaces belles et fluides. Juste une solution qui marche pour ameliorer des fois les choses.
[^] # Re: [:Mouaifff]
Posté par cedric . En réponse au journal Rethinking PID 1. Évalué à 9.
Aujourd'hui, il y a surement bien plus de Linux dans l'embarque que ailleur. Et ca va vraiment plus dans cette direction, smartbook, telephone, homeserver, tablette ...
Toutes ces machines les gens s'attendent a ce qu'elle demarre instantanement. Alors ameliorer le temps de boot et optimiser le systeme, ca interresse beaucoup beaucoup d'utilisateurs, en fait surement la majorite et en plus ceux qui payent !
D'un point de vue pragmatique, le projet qui va surement etre le plus interresse par ce nouvel init, ce sera MeeGo. Donc ca redescendra surement par toutes les distrib qui l'utiliseront.
# Presentation aux RMLL
Posté par cedric . En réponse à la dépêche Archos 5IT : Du linux dans ma tablette. Évalué à 2.
http://2010.rmll.info/Nouvelle-traduction-Archos-mobile-plat(...)
[^] # Re: goto ?
Posté par cedric . En réponse à la dépêche Sortie de GCC 4.5. Évalué à 3.
[^] # Re: goto ?
Posté par cedric . En réponse à la dépêche Sortie de GCC 4.5. Évalué à 4.
[^] # Re: Juste des rumeurs
Posté par cedric . En réponse à la dépêche VP8 : nouveau codec vidéo libre ?. Évalué à 9.
Pour les encodeurs, c'est different. Aujourd'hui, pour le h264, tu as un encodeur libre et performant absolument excellent: x264. Il te fait du live, ou de l'encodage differe de bien meilleur qualite et efficacement que des encodeurs hard. Si On2 a un encodeur soft du meme niveau de qualite, VP8 prend la main demain aussi vite que h264. Et vu la puissance/cout des serveurs aujourd'hui, il faut etre fou pour parler encore d'encodeur hardware pour autre chose que l'embarque.
[^] # Re: Mais nos médias sont-ils encore intéressés par la rationalité ?
Posté par cedric . En réponse au journal [HS] Fin de la récré pour les climato-sceptiques ?. Évalué à 2.
[^] # Re: Sur iphone uniquement ?
Posté par cedric . En réponse au journal L'heure de la Battle for Wesnoth 1.8 a sonné. Évalué à 0.
[^] # Re: Miam !
Posté par cedric . En réponse à la dépêche Enlightenment France l’association. Évalué à 2.
https://bugs.webkit.org/show_bug.cgi?id=35761
[^] # Re: compiz?
Posté par cedric . En réponse au journal Sortie de Elive 2.0 (Debian avec E17). Évalué à 8.
[^] # Re: Portage ARM
Posté par cedric . En réponse à la dépêche Sortie de GeeXboX 2.0-alpha1. Évalué à 1.
[^] # Re: c'est quoi l'intêret ...
Posté par cedric . En réponse à la dépêche Première sortie pour GeeXboX Enna Media Center v0.4.0. Évalué à 1.
Les EFL, c'est portable. C'est un toolkit au meme titre que GTK ou QT qui te fournit un rendu graphique portable et optimise. Les EFL sont entierement modulaire, et tu as de multiple backend, X11, FrameBuffer, DirectFB, SDL, OpenGL, Cocoa, GDI, DirectX, ... Et j'ai surement du en oublier.
C'est meconnaitre les EFL que de croire que c'est d'elle que viendra le probleme de portabilite :-)