Mais pourquoi il faut toujours lier tout ca a Bada...
Chez Samsung, ils ont depuis 3 ou 4 ans, un OS Linux destine, d'abord, au marche Asiatique, SLP pour Samsung Linux Platform. Cet OS ayant ete developpe par Samsung dans le cadre du projet LiMo. Au tout debut, ils ont suivit le reste de la troupe LiMo et fait du GTK. Mais ils se sont rendu compte que ca ne marchait pas bien. Une experience a alors ete lance avec les EFL. Celle-ci, c'est revele tres pertinente, permettant d'avoir des applications reactives et avec le look attendu par les designers. Ils ont donc switche sur les EFL. Ce qui est tres amusant, car les EFL avaient ete considere rapidement au debut du projet LiMo, mais repousse, car ils voulaient une bibliotheque sous license LGPL et non BSD.
Tizen est juste une version de SLP que Intel a aide a rendre publiable. Ca n'a rien a voir avec Bada. Maintenant la rumeur, lance au CES, veut que Bada passe aux EFL comme toolkit graphique et que les API native de Bada soit importe dans Tizen de maniere a proposer un environnement unifie pour developper des applications entre les deux OS de Samsung. Note, que utiliser les EFL comme toolkit graphique est tres flou, car il est completement possible de n'utiliser que evas et de construire une stack completement differente au dessus. Donc pour l'instant le lien entre Bada, Tizen et les EFL, c'est au mieux flou ou alors juste une rumeur...
J'aime beaucoup ce debat sur "ou est l'usine" ! Comme si la majorite de la plus value etait faite en usine. L'usine chinoise gagne 6.5$ par iPad, autant pour le "made in china".
Desole, pas le temps d'essayer de te retrouver les backups. Mais ce n'est pas difficile, tu fais un petit programme avec quelques sprites qui bougent en rebondissant sur l'ecran avec un fond d'ecran, et enfin un layer au dessus pour faire une bordure et un compteur de fps.
Et tu as fais les tests en utilisant les bindings EFL pour .NET/C# ?
Non, ca n'existait pas. Mais ca change rien au fait que tu aurais toujours pcre, la glib et mono. Soit toujours 4Mo de pris au minimum pour ca.
Sinon chez moi, dans 4Mo, j'ai pcre, glib et mono, rien de plus.
Et mscorlib, l'équivalent des bibliothèques de base EFL.
Chez moi, mscorlib, a elle seule, fait 2.5Mo.
Alors juste comme ca, mais ta VM, il faut la mettre integralement en ram, sinon ca va provoquer des lags. La VM, c'est le coup minimal de toutes les applications que tu vas pouvoir faire.
Le runtime peut être partagé en mémoire. Bon sinon, même si ca bouffe 2 ou 3 Mo de plus avec les EFL (imaginons), vu la différence de conso mémoire avec le moindre bench, ca compense largement.
Le runtime, tu veux le partager avec quoi ??? Il n'y a rien d'autre qui tourne ! Et sinon dans ton imagination, tu arrives a concevoir ce que c'est un jeu ? C'est 80% de data en memoire (son, image, ...). Quasiment rien en objet. La majorite des jeux vont jamais te prendre 3Mo pour des objets de ton langage. Par contre, pour tes graphismes et le son oui. Apres pour des benchmark, ou tu fais des calculs scientifique, c'est sur le JavaScript, c'est une bonne idee.
M6 replay et Canalplay sont des offres de replay et non de VoD. La difference est sur les contraintes du contenu joue. Sur les offres de VoD, tu as des films et ils ont des regles de diffusion extrement stricte.
CanalPlay c'est pas du replay, c'est de la VOD.
Pour le coup, je suis tres surpris. Vu comme ils sont super chiant avec les editeur de STB. Je me demande comment Microsoft a negocie son contrat et ce qu'il y a d'accessible comme contenu.
Different pays, different ayant droit, differente regles.
Franchement, c'est quoi le cout de developpement d'apres toi d'une application comme Angry Bird ? Et la majorite des applications vendu sur smartphone et tablette aujourd'hui ? Tu repartis comment d'apres toi, les coups entre le developpement, le game design, les graphismes, les niveaux, le marketing. Et tu estimes que c'est quoi la plus grosse source de revenu pour ce jeu ?
Angry Bird : je dirais 100 000 k pour tout le projet, à la grosse louche, hors marketing. Et ?
Pff, tu es desesperant. Je te demande une repartition entre les differents postes necessaire a la realisation du jeu. Et toi, tu fais juste une enveloppe global au pifometre. L'idee etait de te faire comprendre que le coup developpement sur des petits jeux comme Angry Bird ete quasiment exclusivement sur le game design, les graphismes, les niveaux, ... Mais ca a l'air d'etre complique de concevoir qu'il y a autre chose que du developpement en Mono...
Quelque soit la source de revenu, elle est directement proportionnelle au nombre d'utilisateur : le coût de dev peut paraître dérisoire si tu cible le parc de dizaines de millions d'iPhone, mais il ne l'est pas si tu cible le petit million (à la louche) de Freebox Revolution.
Euh, le truc proprio, c'est toi qui parle de XNA, non ? Elixir et l'integralite de ses dependences sont libres et disponible. J'ai vraiment du mal a suivre ta pense quand tu utilises pas les bons mots pour decrire les concepts auquel tu penses.
Oué enfin là c'est pas moi qui déforme hein, proprio c'est l'opposé de "standard" pas de "libre". Plusieurs on gueulé par ici pour parler plutôt du terme "privateur", on aime ou on aime pas.
Non, proprio n'est pas l'oppose de standard ! Mais c'est pas possible d'etre autant de mauvaise fois et d'essayer au tant de se rattraper a des branches pourries. Pour info, Opera est un logiciel PROPRIETAIRE qui respecte un STANDARD ! C'est deux concepts orthogonal !
Donc ta solution au probleme d'avoir un truc de trop haut niveau, c'est de proposer une autre solution de haut niveau.
Quand je parle Unity, je ne parle pas de la V5 hein, mais de la Revolution. Le problème de la Freebox Revolution, ce n'est pas d'avoir une solution de trop haut niveau, c'est d'avoir un store vide. Moi je propose une solution qui a l'avantage d'être répendue, multiplateforme, et donc permettre de faire tourner pleins de jeux out-of-the-box ou presque.
Youhou ! Le store est vide parce que personne chez Free s'en occupe sur la v6. C'est tout. La solution SDL + OpenGL ES, marche tres bien. Pas la peine de demander a qui que ce soit de tout recoder pour tes beaux yeux !
Je vois meme pas comment tu peux arriver a cette conclusion. Tu n'offres pas plus de liberte au gens ou alors a la marge. Sans compter que faire du dev avec Unity necessite d'avoir un paquet de designer pour arriver a produire un resultat correct.
Gni ? Un designer, c'est pour faire de jolis design, quelque soit la techno.
Mais vu qu'ils sont dependant du processeur Atom, et qu'aucun autre FAI/constructeur de TV n'a choisit ce processeur, ils sont coince.
D'où l'idée d'utiliser un Unity qui s'encombre pas de ce détail ;)
Ca tu en parles a GameTree.TV. Rien a voir avec Free.
Maintenant qu'est-ce que tu veux attirer comme developpeur ? Quelque soit la solution, il faut, pour faire le developpement, etre en France.
D'où l'idée d'utiliser des solutions cross-plateformes. Sinon totalement d'accord avec toi, rien à péter des jeux libres, pour l'essentiel loin des attentes des utilisateurs lambda.
Faut arreter avec ton reve de cross plateforme. Les editeurs de jeux ont deja des solutions maisons ou du marche. Ils veulent un truc bas niveau qui marche et soit bien documente. Faut pas aller chercher midi a quatorze heure non plus.
Non, 32Mo, c'est la v5. C'est un thread sur la v5 HD a la base... La v6 a environ 1Go de RAM a se partager entre le GPU, la decompression video et le systeme.
Android pour TV n'existe toujours pas. Le NDK ne marche que sur ARM. Et il suffit de voir l'opinion de Logitech sur la question pour ce dire que c'est une bonne idee d'eviter Android sur une TV pendant encore quelque temps.
J'ai arrete d'utiliser ce site, car les benchs sont mal ecrit et certain language utilise des facilites qui sont interdit a d'autre.
Alors qu'est ce qui te permet d'affirmer que C#/Mono bouffe plus de mémoire que SpiderMonkey ? Moi je te pointe des tests, qui valent ce qu'ils valent, mais qui sont factuels : pour les tests de ce site, Mono bouffe nettement moins de mémoire que V8. J'attend tes résultats avec SpiderMonkey.
Desole, pas le temps d'essayer de te retrouver les backups. Mais ce n'est pas difficile, tu fais un petit programme avec quelques sprites qui bougent en rebondissant sur l'ecran avec un fond d'ecran, et enfin un layer au dessus pour faire une bordure et un compteur de fps.
Enfin, pour information, les EFL + Elixir + SpiderMonkey, ca prend 3Mo au complet avec toutes les dependences. Ce qui doit etre la taille de juste la VM mono sans aucune de ses dependences...
Ok, c'est plus les perfs, c'est plus la conso mémoire, maintenant c'est la taille de l'exécutable : la VM mono avec ses dépendances + l'équivalent des EFL sans les API IHM, c'est 4 Mo (cf MonoTouch).
Alors juste comme ca, mais ta VM, il faut la mettre integralement en ram, sinon ca va provoquer des lags. La VM, c'est le coup minimal de toutes les applications que tu vas pouvoir faire. Certe tu as un coup par objet ensuite, mais le coup de ta VM quand tu as 32Mo, il n'est pas negligeable (Accessoirement ils augmentent le temps de chargement). Sinon chez moi, dans 4Mo, j'ai pcre, glib et mono, rien de plus.
LOL ! J'avoue la, niveau credibilite, tu viens d'atteindre des sommets ! La XBox, c'est une console, c'est concu pour faire du Jeux. Ca se vend que comme ca, et ca ne vend que ca. Mais le materiel, ses capacites et son public n'ont rien a voir avec celui des TV ou des Set Top Box. Donc c'est juste pas le meme marche et ca n'a juste rien a voir. C'est une bonne idee de parler des consoles, mais c'est a cote de la plaque encore une fois.
La xbox et la freebox sont tellement différents que :
- La XBox a des offres de VOD (M6 replay, Canalplay, etc.)
M6 replay et Canalplay sont des offres de replay et non de VoD. La difference est sur les contraintes du contenu joue. Sur les offres de VoD, tu as des films et ils ont des regles de diffusion extrement stricte.
La XBox fait lecteur multimédia, renderer DLNA
DLNA, c'est un truc de geek. C'est pas la mamie du cantale qui va jouer avec.
La Freebox Revolution se veut une console de jeux
Non, elle se veut un equivalent a ce que propose un iPhone, du casual gaming. Elle est d'abord une interface tv. Ce n'est pas parce que ca se branche sur une TV et que ca affiche un jeu que c'est forcement adresse au meme public. La Xbox vise des gamers, des gens qui vont depenser de l'argent pour jouer. La Freebox, tout comme les TV et autres STB, s'addresse d'abord au grand public qui veut regarder la TV et avoir des services en plus sans trop depenser d'argent. D'ou aussi une difference de prix important entre les jeux que tu trouves sur Xbox et ceux que tu trouves sur Freebox TV.
En fait, à part le fait que la XBox ne permette pas de matter les chaîne TV en direct... quoique c'est une spécificité du marché français hein, aux US on peut matter des chaîne live sur la XBox.
C'est juste une detail finalement, la Xbox, c'est une set top box sans la TV... Et dire qu'a une epoque, une set top box n'etait sense faire que ca ! Mais sinon j'ai une chemine sous ma TV, c'est un succes planetaire depuis des siecles, preuve de son modele economique. Le market associe est un peu limite, mais ca n'a pas empeche des fournisseurs locaux de bois (apperement le kit de developpement est plutot dedie a des bucherons) de bien se developper...
Dire que les usages sont totalement différents, voilà quoi.
C'est vrai, c'est tellement sur fait une TV qui affiche la TV. La preuve ma chemine, a part le fait qu'on ne peut pas regarder la TV avec, c'est comme une TV...
Appel l'a demontre en lancant son Store avec un language ObjC que personne ne connaissait et un SDK qui marchait a l'epoque que sur les produit Apple.
Qui ne marche d'ailleur toujours que sur les produits Apple. Mais, même si je suis d'accord que l'ObjC est un frein, il reste que l'environnement de prod est cohérent, directement fonctionnel, l'émulateur de qualité, et les tests sur device simplifié vue la gamme "étroite" cible. Ajoute à celà une base utilisateur importante, et le ratio investissement dev / revenus potentiel était relativement attrayant.
Non, l'environnement de dev est devenu coherent. Il ne l'etait pas au debut et a mis du temps a l'etre. Le cout de developpement ete tres eleve au debut.
Oui il est depuis largement dillué, effectivement pour avoir rencontré "trop" de succès. Il devient effectivement difficile de faire de la thune pour indépendant sur cette plateforme. Mais bon on est loin d'avoir ce problème sur la Freebox.
Justement, le point est de te faire remarquer qu'il n'y a pas de regle general qui se resume a la technique dans le succes d'un projet.
Android, même si l'environnement est vraiment bancale et les outils mal foutus, l'investissement pour le dev reste raisonnable : langage simple et connu, environnement connu (Eclipse), tourne partout (donc gratuit), coût de déploie faible. Et le résultat es là : le market est bourré à craquer. Pleins de défauts, de gros problème de qualité du fait d'un parc de device morcelé, mais la Freebox n'a pas ce problème.
Le market est bourre d'application pourri et inutilisable. Il faut vraiment faire un gros effort pour y trouver quelque chose de bien. Tu as un regard biaise sur le sujet. Mais a part les geek, android demotive beaucoup ses utilisateurs... Si je ne me trompe les stats de changement d'OS sont actuellement en faveur de l'iphone d'ailleur (plus de gens qui passe de android a iOS que l'inversement). Et les utilisateurs iOS depense plus que les utilisateurs Android dans leur store/market respectif.
De maniere generale, les outils sont secondaire si tu fournis un moyen aux developpeurs de s'y retrouver financierement.
Ca forme un tout : si le coût de développement est trop important, l'intérêt financier est largement diminué, le risque trop gros. Tu prends que les exemples de store qui ont marchés, mais tu oublies ceux qui ont "foirés" : prends par exemple la Playbook : suffit de voir les réactions des éditeurs quand on leur demandait de porter leurs applis : l'environnement technique de développement a été un très gros frein.
Le plus gros frein du playbook, absence total d'utilisateurs. Tu rajoutes a ca une plate forme catastrophiquement lente et faut pas esperer grand chose forcement. Mais comme tu le fais remarquer, chaque store depend fondamentalement de l'environnement dans lequel il est. Tu veux absolument demontrer que la reussite ou l'echec d'un store est uniquement lie a la technique et tu en retiens que ce detail. Mais au final, meme dans ton exemple, le premier probleme, c'est quand meme l'absence d'utilisateur et la technique n'est qu'un second probleme.
Les exemples montrent clairement qu'il n'y a pas de regle universel, surtout technique, qui regissent la reussite ou l'echec d'un store. Chaque marche doit s'adapter a ses utilisateurs pour reussir.
ne faira pas vendre plus d'application, si elles n'ont pas un modele economique valable.
On est d'accord : il faut un bon modèle économique. Moi je le résume à coût dev investissement vs revenus potentiels. Les 2 sont pour moi important même si pour toi il y en a 1 qui est secondaire.
Franchement, c'est quoi le cout de developpement d'apres toi d'une application comme Angry Bird ? Et la majorite des applications vendu sur smartphone et tablette aujourd'hui ? Tu repartis comment d'apres toi, les coups entre le developpement, le game design, les graphismes, les niveaux, le marketing. Et tu estimes que c'est quoi la plus grosse source de revenu pour ce jeu ?
Sur les TV et les set top box, il n'y a encore eu tres peu d'inovation pour permettre aux developpeurs de rentabiliser leur developpement.
Le problème, c'est pas le manque d'innovation, c'est surtout que chacun y va de sa petite plateforme, de son petit truc proprio dans son coin. Du coup le nombre de clients
Euh, le truc proprio, c'est toi qui parle de XNA, non ? Elixir et l'integralite de ses dependences sont libres et disponible. J'ai vraiment du mal a suivre ta pense quand tu utilises pas les bons mots pour decrire les concepts auquel tu penses.
potentiels est relativement faible pour une plateforme cible, et le coût de développement n'est pas rentabilité. Mais prenons l'exemple de la Freebox Revolution : pourquoi ne pas travailler avec un Unity par exemple ?
Donc ta solution au probleme d'avoir un truc de trop haut niveau, c'est de proposer une autre solution de haut niveau. Je vois meme pas comment tu peux arriver a cette conclusion. Tu n'offres pas plus de liberte au gens ou alors a la marge. Sans compter que faire du dev avec Unity necessite d'avoir un paquet de designer pour arriver a produire un resultat correct.
Le coût de développement serait largment diminué, cross-platform oblige, et vous auriez un store qui se remplirait et deviendrait viable ! De ce que j'ai compris, vous essayé plutôt d'attirer les développeurs Windows avec une compatibilité avec les jeux PC, mais le store est désespérément vide, pourquoi ? Vous limitez volontairement à un seul éditeur ?
Tout d'abord, je ne suis plus chez free depuis quelques mois. Pour repondre a ta question, il y a actuellement 3 SDK pour faire des jeux, Elixir, SDL + Open GL ES et Cedega.
Cedega est completement controle par une societe exterieur. C'est elle qui gere ses contrats et essayent de ramener des jeux sur sa plateforme qui se veut justement cross plateforme. Mais vu qu'ils sont dependant du processeur Atom, et qu'aucun autre FAI/constructeur de TV n'a choisit ce processeur, ils sont coince.
SDL + OpenGL ES a ete developpe pour permettre le portage quasi direct d'appli iPhone sur Freebox v6. C'est ce que fait GameLoft et leur difficulte de portage est uniquement sur le fait qu'il ne connaissait pas Linux au debut.
Maintenant qu'est-ce que tu veux attirer comme developpeur ? Quelque soit la solution, il faut, pour faire le developpement, etre en France. Tu te limites forcement au studio francais, car le genre de jeux dont on parle necessite bien plus que du dev, donc les independant auront forcement du mal. Etant donnee les nombres, de mon point de vue, il suffit de travailler en direct, sur le meme principe qu'avec GameLoft, d'avoir une gestion un peu plus subtile et sympatique du store pour que ca marche. Un SDK natif ouvert apportera au final peu de jeu nouveau de bonne qualite. Bien sur, cela permettrait d'avoir le portage des jeux libres dessus. Mais ils ne sont pas tres nombreux et si un developpeur s'en occupe a plein temps, en an, tous les jeux libres seront disponible sur la v6. En tout cas, c'est mon point de vue.
J'ai arrete d'utiliser ce site, car les benchs sont mal ecrit et certain language utilise des facilites qui sont interdit a d'autre. Il n'y a aucune information de comparaison pertinente. De plus, la comparaison que tu pointes est faite sur V8 et non SpiderMonkey. Enfin, pour information, les EFL + Elixir + SpiderMonkey, ca prend 3Mo au complet avec toutes les dependences. Ce qui doit etre la taille de juste la VM mono sans aucune de ses dependences...
Il a ete possible sur certaine generation d'iPhone de mettre en place un jailbreak juste en allant sur une page web.
Et ? Le problème était dans le navigateur web, pas dans une appli ! Le problème peut apparaître de manière identique sur la Freebox qui est équipé d'un navigateur avec le même niveau de complexité et de sécurité que celui d'un iPhone.
C'est bien, tu quote juste une partie de mon message. Si tu parles de la v5, c'est juste faux, si tu parles de la v6, alors oui, la surface d'attaque est superieur.
Et aujourd'hui ne t'en deplaise, le JavaScript voit ses VM evolue plus vite et obtenir plus d'amelioration que tout autre langage de script !
Oué mais laisse tomber les langages de script, la plupart sont conçus "by design" pour ne pas être performant. Je t'ai montré par A+B qu'il y avait beaucoup plus pertinent, et tu ne m'a absoluement pas montré le contraire.
Je dois avoir loupe l'addition de A+B, parce que a part des grandes phrases sans aucun contenu technique ni prise en compte des contraintes, je n'ai rien vu. Et non, faire du natif, n'est absolument pas trivial contrairement a ce que tu as l'air de croire.
c'est juste n'avoir aucune idee des contraintes rencontre et du profil d'une application.
Ben je sais pas : tu me sors des contraintes : perfs, mémoire. Je te montre par A + B que y'a pleins d'autres choix qui répondent beaucoup mieux à la problématique, ta seule réponse, c'est "on s'en fou c'est que 20% et de toute façon JavaScript a été conçu pour un Pentium75". Je te répondrais que le Java existait même avant le premier Pentium.
A+B n'est pas un argument technique. Tu me parles Java et Mono, je te dis pourquoi ces deux languages specifiquement ont ete elimine. Et oui, le Java existait avant le premier Pentium. Par contre, tu l'as deja utilise ? Parce que niveau temps d'initialisation, ressource consomme par la VM, je suis desole, mais ca fait 15 ans que je n'ai jamais trouve une seule application correcte et utilisable en Java.
Et concernant le : "on s'en fou", c'est juste que le seule effort qui vaudrait la peine serait d'utiliser un JIT JavaScript, qui donnerait des perfs plus interressante, mais l'effort necessaire vs le gain serait faible. Il y a d'autre chose a faire qui sont plus utile pour un tel projet. On vit dans un monde avec des contraintes physiques a prendre en compte, et cela impose de prioritise les choses pour maximiser le resultat obtenu.
La Freebox v5, c'est un MIPS a 200Mhz
On s'en branle de la v5, la v5 a des perfs pourris et aucun jeu pertinent sorti dessus. La seule première vraie box qui répond potentiellement à ce besoin, et qui est vendu avec cet argument marketing, c'est la Revolution. Mais je comprends mieux la divergence de nos point de vue : tu parles du kit de la v5, moi je parle de la dernière box. Visiblement il y a un SDK "natif" pour la Revolution à destination des éditeurs. C'est tout de suite plus pertinent, mais vu que j'ai accès à aucune doc, je suis incapable de juger.
Bon, ben, relis le post de depart alors. On parle de la Freebox HD, la v5, depuis le debut. C'est sur si on parle d'autre chose, on va pas avoir les meme conclusion. Deja sur la v6, tu n'as pas actuellement de SDK ouvert. Donc, je vois meme pas de quoi tu peux parler. Pour ce qui est du SDK natif, c'est du SDL + OpenGL ES en C/C++. Les contraintes de cette box, voir mon post precedent, sont totalement different. Le processeur fournit beaucoup plus de mode de securite. Il y a beaucoup plus de memoire (1Go). La ou le bas blaisse, c'est le GPU qui est pas top et necessite de bonne competence en OpenGL ES pour reussir a en tirer quelques choses. Mais globalement le rapport de puissance avec la v5, c'est un facteur 10. Ce n'est pas encore une console de jeu, mais tu as deja plus de liberter de developpement.
Il n'y a pas d'autre market/store qui existe actuellement sur les TV.
lol et c'est quoi le XBox Live et son market en ligne ? Une box inconnue d'un obscure fournisseur internet d'amérique latine ?
LOL ! J'avoue la, niveau credibilite, tu viens d'atteindre des sommets ! La XBox, c'est une console, c'est concu pour faire du Jeux. Ca se vend que comme ca, et ca ne vend que ca. Mais le materiel, ses capacites et son public n'ont rien a voir avec celui des TV ou des Set Top Box. Donc c'est juste pas le meme marche et ca n'a juste rien a voir. C'est une bonne idee de parler des consoles, mais c'est a cote de la plaque encore une fois.
Les problematiques sont plutot que pour qu'un store vive, il faut le gerer et pas le laisser s'auto gerer
Pour qu'un store vive, il faut du contenu, et encore du contenu. C'est la clé, le reste, c'est de la foutaise. Pourqu'il y est du contenu, il faut des développeurs : il faut leur vendre une base d'utilisateurs potentielles et leur proposer des outils où ils sont productifs, pour que le ratio coût de dev/ revenus potentiels soit le plus attrayant possible.
Je pense que tu es tres porte sur la technologie et le developpement, mais tu manques de recul. Pour avoir un bon ratio cout de dev / revenus potentiels, les outils et le language ont assez peu d'importance.
Appel l'a demontre en lancant son Store avec un language ObjC que personne ne connaissait et un SDK qui marchait a l'epoque que sur les produit Apple. Par contre, ils avaient un bon travail de visibilite et le ratio offre / clients etaient tres bon au debut, ce qui a permit a quelques developpeurs de bien amortir leur developpement. Mais aujourd'hui developpez pour les produits Apple devient difficile et rapporte peu, trop de concurrence, peu de visibilite, croissance de la base de developpeur supperieur a celle des acheteurs d'applications. Conclusion les developpements qui marchent actuellement, ceux sont les applications pour les marques. Le reste rapporte marginalement et ne permet que difficilement pour les developpeurs independant de reussir.
Sur Android Market, le systeme est different. L'achat a l'acte est faible, le piratage eleve. Par contre, la publicite dans les applications rapporte, tous comme les achats in-apps. Il y a donc un interet de fond a faire des bonnes applications que les utilisateurs vont utilises longtemps pour que la publicite soit visible le plus longtemps possible. L'environnement de developpement d'Android et la difficulte de faire des tests sont faramineux sur cette plateforme morcele, mais si une application est bien faite alors elle peut rapporte gros et pendant longtemps.
De maniere generale, les outils sont secondaire si tu fournis un moyen aux developpeurs de s'y retrouver financierement. Faire plaisir a titi parce que sont language fetiche, c'est le C# et pas le Java ou si il prefere le Brainfuck, ne faira pas vendre plus d'application, si elles n'ont pas un modele economique valable.
Et cette lecon s'applique aussi a d'autre contexte, tu prend une Nintendo DS, la majorite des jeux ont fini pas etre des trucs pour gamine, parce que tout simplement c'etait les seuls a ne pas se faire pirater et a avoir un retour sur investissement correct. Ca n'a rien a voir avec la technique. Ca reste toujours une question de comment les developpeurs peuvent gagner de l'argent.
Sur les TV et les set top box, il n'y a encore eu tres peu d'inovation pour permettre aux developpeurs de rentabiliser leur developpement. Le modele economique est encore a creer et pour l'instant le Freestore n'apporte rien dans le domaine que ce soit en v5 ou v6 qui reponde a ce probleme. Peut-etre que l'arrive d'une nouvelle generation de Google TV ou d'une hypotetique Apple TV changera la donne, mais pour l'instant ca manque d'innovation pour creer un veritable eco-systeme rentable.
Alors pour reprendre ta liste. Dalvik n'existait pas et le Java en general consomme trop de memoire. Meme probleme pour mono et le C#. Le SandBoxing d'application C++ demande un peu d'aide du CPU que tu n'as pas sur MIPS.
Et les contraintes d'Apple en terme de securite sont faible compare a celle d'une set top box. Il a ete possible sur certaine generation d'iPhone de mettre en place un jailbreak juste en allant sur une page web. Des chercheurs en securite, on demontrait qu'ils arrivaient a sortir facilement de la sandbox de l'iPhone depuis une application de l'Apple Store. Toutes ces failles de securite sont considere comme extremement grave sur une set top box et genererait l'arret immediat de tous les services de video a la demande et de TV. Les contraintes de securite ne sont absolument pas les meme !
De plus, penser que le JavaScript est la source d'une limitation des performances, c'est juste ne pas avoir la moindre idee du profil d'execution d'un jeu ou d'un logiciel. Tu passes plus de temps dans les routines graphiques et sons que dans la logique de ton jeu. Ce n'est pas donner l'ordre de deplacer un sprite qui prend du temps, mais bien celui de le dessiner a l'ecran qui va occuper la machine. Pour info, dans l'ensemble des jeux actuellement disponible, le plus gros consommateur de JS, occupe seulement 20% dans les routines lies au JavaScript. Certe ca serait plus sympa d'avoir un JIT et tu pourrais faire un peu plus, mais meme avec une multiplication par 10 des perfs du langage choisit, ca ne changera pas que tu ne pourras pas gagner sur les 80 autres pourcents ! Et sinon, tu sais de quelle epoque ca date le JavaScript ? D'une epoque ou la norme n'etait pas d'avoir chez soi mieux qu'un pentium 75 avec 64Mo de RAM. Ca correspond exactement au contrainte du materiel de la v5 (qui a plutot 32Mo de RAM). Et aujourd'hui ne t'en deplaise, le JavaScript voit ses VM evolue plus vite et obtenir plus d'amelioration que tout autre langage de script !
Donc dire que n'importe quel autre choix aurait ete plus judicieux, c'est juste n'avoir aucune idee des contraintes rencontre et du profil d'une application.
D'ailleur vu tes idees, OpenGL, Unity3D et XNA, je pense que tu n'as juste aucune idee de quoi tu parles ! La Freebox v5, c'est un MIPS a 200Mhz, avec 5 plans graphiques et un blitter. Tu peux meme pas decompresser des sons en hard, si tu veux pouvoir les mixer apres. Et toi, tu reves gentillement d'OpenGL et XNA...
Sur la V6, tu peux commencer a l'envisager, le processeur gere la virtualisation et le GPU fait de l'OpenGL ES, potentiellement meme de l'OpenGL. Mais sur la v5, c'est juste completement irrealiste ! Des fois, il y a des contraintes materielles a prendre en compte, la realite du monde physique, des choses comme ca. Avoir de grandes idees, c'est bien, mais realiser quelques choses qui marche, c'est mieux.
Pour repondre enfin a ta derniere question, il y a autant d'appli sur le Freestore que sur le magasin online subventionne de Samsung pour ses TV. Il n'y a pas d'autre market/store qui existe actuellement sur les TV. Meme Google et Apple n'en ont pas fait pour l'instant. Et non, ca ne se compare pas aux jeux sur portable, ni aux jeux en flash, car il faut forcement penser l'ergonomie d'un jeu pour la plateforme sur laquelle tu le vends, sinon il sera juste injouable !
Enfin, la taille du marche est aussi a compare au revenu potentiel et a la competition. Si tu es tout seul a faire un jeu et qu'il y a 4millions de clients, c'est mieux que si tu es 1millions a faire des jeux pour 300millions d'individu. La preuve en est, un bon jeu comme BounceBox developpe par un unique developpeur dans son coin a genere plus d'un million de parti.
Les problematiques sont plutot que pour qu'un store vive, il faut le gerer et pas le laisser s'auto gerer. Mettre en avant les jeux les plus reussi, nettoyer les applications trop pourri, permettre de tester avant d'acheter, fournir des teaser, des versions d'essais, mettre en place des mecanismes de promotion et plus de source de revenu potentiel pour un jeu ... En gros, si tu veux vendre, il faut mettre en avant le contenu, et pas juste faire un listing dans une interface mediocre. Croire que le probleme est au niveau de la technique te faira croire qu'en proposant juste un truc avec plus de technique tu resoudras le probleme. Mais si le Freestore sur la v6 n'est pas ameliore, le resultat ne sera pas meilleur, voir meme peut etre plus mauvais. Les difficultes du developpement natif en plus.
Je vais te repondre juste concernant le SDK et ta question concernant la SDL. Tout d'abord, essaye de jouer a Doom et Duke Nukem 3D en mettant le .wad de doom ou les data necessaire de Duke Nukem sur le disque dur de ta Freebox HD. Tu vas tres vite te rendre compte que les performances ne sont pas enorme. Seul la resolution la plus basse est jouable.
SDL est un layer graphique simple a utiliser et qui n'offre aucune acceleration materiel correct. Resultat tous les jeux essayent avec leur moyen de faire un rendu graphique correct. Mais il n'y a pas grand monde capable de faire un pipeline de rendu optimise dans le monde du logiciel libre, resultat il a part Doom et Duke Nukem, il n'y a aucun autre jeu libre qui pourra passer.
Le second point a ne pas oublier, c'est les contrats avec les fournisseurs de contenu. Ceux-ci sont souvent fermement opposer a l'existence de code natif sur la meme machine et il y a une difficulte non negligeable a fournir un SDK natif utilisable sur l'architecture de la v5.
Tu prends ces deux points ensemble, et tu en conclus qu'il n'y a pas d'autre solution technique que d'utiliser les bibliotheques d'Enlightenment. Pour les autres toolkit, Qt faisant un OOM avant meme de pouvoir afficher quoi que ce soit, et GTK mettant 5min pour afficher une frame. Les ressources materiels disponible limite clairement les possibilites. Enfin le langage de script choisit, JavaScript, est actuellement le plus utilise et recoit une feroce competition entre Apple, Google, Microsoft et Mozilla. Donc le choix le plus perein dans le temps. Meme si aujourd'hui, j'aurais tendance a partir plutot sur v8 plutot que SpiderMonkey (mais ce dernier n'etait pas encore disponible a l'epoque pour MIPS).
PS: la sortie SPDIF doit permettre de sortir du 5.1, je dirais.
En R&D, c'est effectivement legerement different. Il y a des efforts dans tous les sens pour tenter des trucs, des fois, ca marche, des fois, ca marche pas. C'est le cas pour je pense toutes les societes qui font de la R&D.
Mais a ma connaissance, Tizen n'est plus un projet de R&D, et c'est l'equipe en charge du projet SLP Enlightenment qui est aussi en charge de fournir, ce qu'on appel Tizen. Et etant donnee les delais, moins de 6 mois pour faire un terminal mobile, tu peux etre sur qu'ils ne partiront pas from scratch.
La raison de la communication sur HTML etant a mon avis plus une volonte de rassurer les operateurs et de surfer sur le buzzword du moment. Plutot qu'une raison technique. Il n'y a qu'a regarder ce qu'est WAC pour se dire qu'on ne peut pas faire rapidement quoi que ce soit de serieux avec.
Et oui, j'ai evite de parler du centre de R&D de Londres, car je ne connais pas leurs activites pour l'instant. Ils ont aussi un centre de R&D en Pologne, je crois, ou dans un pays proche, qui a fait pas mal de devs Linux bas niveau et noyaux. Mais cela sans etre lie au projet SLP a ma connaissance. C'est une tres grosse societe, donc la vue et les informations sont forcement partielles. Je ne connais que le travail d'une partie de l'equipe SLP Enlightenment et ca fait deja un paquet de monde. Samsung m'ayant sponsorise pour l'amelioration des performances du rendu video dans le canvas des EFL de juin a octobre. L'ensemble des developpements etant entierement libre et completement integre des le depart upstream.
Vu la taille de la societe, annoncer que 90% de leur projet sont jete, ca serait juste faramineux ! Je ne sais pas dans quelle branche de Samsung, tu as travaille, mais elles sont toute construite de maniere independante et en competition. Leur management est different et leurs objectifs aussi. Il n'est pas possible de comparer la branche Android a la branche Windows Phone ou Bada ou SLP.
Celle qui nous interresse ici, c'est la branche SLP qui a depuis longtemps migre tous ses efforts sur Enlightenment et laisse tomber GTK+ pour des problemes de perf. Ils commencent a avoir une bonne comprehension de ce qu'est le logiciel libre. Il y a encore du travail, mais ca evolu dans la bonne direction pour l'instant. Il est vrai qu'on est, tant que le logiciel et un device ne sont pas libere, dependant de decision de manager, mais ils ont encore le droit au benefice du doute.
De plus et a ma connaissance, personne en France ne travaille chez Samsung sur le projet SLP pour l'instant. Leur R&D se trouvant principalement en Israel et en Coree (Ils doivent aimer vivre dangereusement...).
Tout simplement parce qu'il faut verifier que tous les morceaux de code ont les bonnes licenses et peuvent etre publie. Samsung doit verifier qu'il a bien les droits de publication de tout le code et les morceaux qui manquent doivent soit etre recoder soit etre renegocier.
Intel arrive derriere pour s'assurer qu'ils ont un systeme qu'il build correctement et que l'ensemble marche comme attendu. En fait, le developpement a deja eu lieu, Intel a juste convaincu Samsung d'en faire une plateforme de developpement ouverte. Donc la problematique n'est pas de faire le dev derriere des portes closes, mais d'ouvrir ces portes.
Actuellement le seul terminal annonce avec un avenir, c'est Tizen, le reste c'est juste du truc de geek qui n'ira jamais plus loin qu'une rom pour afficionado dans leur coin. Dis comme ca, c'est clairement violent, mais il faut etre realiste, sans un terminal et une societe avec les moyens de le marketer, ca ne donnera rien de credible.
Pour ce qui est de Tizen, l'annonce a ete clairement fait trop tot. Il n'y avait aucune urgence a communiquer sur le sujet avant que le code source soit libere. Et comme ca ne se fait pas en 5 min, et bien, on se retrouve dans une situation ou on a l'impression d'avoir du vaporware. Sauf que le terminal Tizen, il existe bien et il y a une bonne centaine d'ingenieur qui travail dessus chez Samsung dans le but d'en faire un produit grand public et utilisable.
Maemo, Harmattan et Meego sont mort suite au decision de Nokia. En fait, Meego est mort le jour ou Nokia a decide que l'interface utilisateur ne serait pas libre. Cela a fait de meego, yet another distribution. Avec toutes les difficultes qu'il y a a creer du logiciel embarquer rapide, fiable et utilisable, ils ont rajoute la difficulte de maintenir leur propre distribution. Enfin, il y a un autre probleme avec Meego, c'est Qt qui est vu par tous les industriels des telecoms comme etant une technologie controle par Nokia. Alors forcement, le destin de ces systemes sont completement lie a Nokia, si ont un jour avoir un produit grand public.
Si on prend tout ca en compte, on comprend mieux une parti de la communication autour de Tizen. Le choix de HTML, une technologie que personne controle, mais que tout le monde connais. Le choix de se baser sur LiMo, un consortium d'industriel des telecoms. Le choix de partir sur la version de Samsung, SLP, qui fonctionne deja et a une stack logiciel complete pour l'embarque. Alors oui, l'avenir d'un device est lie au decision de Samsung, aujourd'hui. Oui, tant que le code n'est pas ouvert, on ne peut rien dire. Mais clairement, il y a eu une prise en compte des erreurs passees jusqu'a maintenant. Et si il release l'integralite de Tizen, UI compris, alors oui, ils demontreront qu'ils ont pris en compte l'histoire. Samsung n'est pas Nokia, et pour l'instant, on peut leur laisser le benefice du doute.
A l'heure actuelle seul Intel et Samsung travaille sur Tizen pour en preparer sa release. C'est un travail important et qui ne peut se faire que derriere des portes closes. Il est donc normal qu'aucune contribution externe n'est lieu pour l'instant et que les developpeurs independant prennent ca pour du vaporware. Mais ca n'empeche que le code et le terminal existe deja :-) Il faut donc prendre un peu tout ca avec du recul et analyser la situation sans prendre en compte sa propre frustration de ne pas encore avoir un telephone vraiment libre et cool de disponible !
La resistance au changement, le manque de diplomatie et le fait que ca rajoute du travail a des equipes qui ont deja du mal a fournir un systeme competitif face a Linux. Juste des idees comme ca...
Tous ces projets autour de git sont tres interressant. Trac etait bien, mais il mettait une barriere a l'entree plus eleve pour les nouveaux contributeurs. Envoyer un patch ete complique, alors qu'avec git et les merge request, participer a un projet devient trivial.
C'est la ou les outils de revue de code deviennent tres important, gittorious et github permettent de faire des commentaires par ligne de code, est-ce gitlab le permet ? Il est aussi possible de noter un patch et quand celui-ci passe une limite, il est automatiquement merge upstream, est-ce que gitlab le permet ?
Sinon avec svn et trac, on pouvait automatiser la fermeture d'un bug lors d'un commit. Est-ce que c'est possible de faire de meme avec git et gitlab ?
Sinon le truc que je trouve tres domage avec en tout cas gittorious, c'est qu'il est absolument pas possible de retrouver les commentaires d'un patch une fois que celui-ci a ete applique upstream via la ligne de commande. Ca serait tellement plus sympa de pouvoir les obtenir lors d'un git log.
Et de maniere symetrique, c'est domage qu'on ne puisse pas faire de la revue de code ou de la resolution de bug offline. Ca serait tellement puissant si on pouvait faire tout ca offline, recuperer par un git pull toutes les merge request, etudier chaque serie de patch, faire des annotations, tester la compilation et le resultat, puis une fois fini, pousser les commentaires et la note du merge request. Pour pas mal de developpeur, un outil web est nettement moins efficace que la ligne de commande...
Le probleme sur lequel tu mets le doigt, c'est surtout qu'on n'a pas d'outil dedie aux designers, ergonome et graphiste pour faire un theme et qu'ils sont donc oblige d'avoir des methodes de developpements. C'est a dire de passer par un simple editeur de texte, compiler le theme, le tester, detecter les problemes et recommencer. Pas tres efficace, pas tres visuel et effectivement loin de leur pratique habituel.
Ensuite pour repondre a ton message precedent, effectivement E17 contient pas mal de code ecrit depuis des annees qu'on n'a pas envie de toucher tout de suite. Entre autre exemple, les boites de configuration ne sont pas decrit en Edje, donc on ne peut pas en changer leur layout facilement. E17 n'utilise pas Elementary. Mais a un moment donne, si on veut faire une release, il a fallu faire le choix de mettre en standby ces changements et ameliorations.
Avec les EFL, c'est juste un changement de theme. Tous n'est pas techniquement operationnel aujourd'hui pour ca, mais les bases sont la. La premiere chose a bien comprendre, c'est la separation claire entre logique et interface grace a Edje. Cela veut dire que tu peux changer toutes l'interface en changeant juste le theme. Le theme est en charge du layout. Il peut te creer tes listes, tes boutons, definir leur deplacement et transition. Donc oui, le theme defini l'ergonomie de ton application dans le monde des EFL et pas uniquement une image dans un coin ou la couleur de la font.
Biensur, il y a des choses qui sont fondamentalement different entre tous les terminaux. En premier lieu, la precision du pointeur (taille du doigt sur un touchscreen vs souris) et ensuite le dpi qui fait qu'une font va etre lisible ou non. Cela implique des regles strictes quand a la maniere de redimensionner les objets a l'ecran. Ceux sont des contraintes fournit par le profile du terminal et pris en compte automatiquement par les EFL. Enfin le dernier point et que tu souleves avec raison, c'est l'interactivite, l'exemple type, c'est une liste vertical dont on espere qu'elle sera "kinetic" sur un touchscreen et classic avec une barre de navigation sur un desktop. Tu peux rajouter la navigation entre les widgets a l'aide de la touche Tab (Desktop) ou d'une croix directionnel + entre (TV et Set Top Box). Mais cela aussi fait partie du profile. Au final, cela reste un comportement gerable principalement dans le toolkit graphique via un profil.
Donc l'ergonomie d'une application peut etre juste gere par le theme et le profile de notre point de vue et c'est ce vers quoi l'on tend.
QtQuick/QML n'est pas comparable avec ceux dont on parle dans les EFL, car il ne gere pas tout ce que je viens de decrire automatiquement et il faut rajouter cette logique dans le QML. En fait, c'est un defaut de conception inherent a cette technologie, il est necessaire de mettre de la logique de ce cote la. Cela donne plus de souplesse et permet de rapidement faire des prototypes, mais avec le temps se pose des difficultes de maintenance et de performance.
Parce que ta version Qt pour telephone est completement differente de ta version pour Desktop aussi peut etre. En tout cas, les widgets disponibles sur N9 n'ont rien a voir avec ce que tu peux avoir sur Desktop.
Enfin avec les EFL, la problematique sur Desktop, c'est juste une histoire de theme et de profile. Pas franchement de code. En fait, en se focalisant sur de l'embarque riche, on fonctionne par defaut sur n'importe quel desktop. La demarche inverse n'etant pas vrai. Et on parle d'embarque riche ici, c'est a dire que l'on veut avoir les meme fonctionnalites que sur un desktop lourd.
En fait, si tu n'as pas remarque la plus part des tablettes/telephones commencent a etre livre avec une sortie hdmi et un port usb hote. L'objectif, c'est que tu lances exactement la meme appli, exactement le meme code, mais que le theme et le profile soit different par ecran. Et ton appli s'adapte directement a l'ecran en fonction de son type, tv, ecran pc ou video projecteur. Je te laisse imaginer toutes les implications de ce genre d'idee et ce que tu peux en faire. Mais c'est ce sur quoi on travaille et c'est ca l'objectif de faire une bibliotheque pour l'embarque, que tu n'es plus besoin de ton desktop actuel.
Malheureusement non. C'est le point qui peche le plus. On a des trucs dans les cartons, mais rien de reelement concret/utilisable. Cela deviendra surement la priorite apres la release de E17.
Peut-etre parce qu'une fois qu'on a optimise quelque chose, son profil change et donc que l'on peut optimiser quelque chose d'autre. Il y a aussi le contexte materiel qui evolue. Aujourd'hui on est partie pour avoir du multi-coeur dans tous les environnements. Il devient donc interressant d'optimiser la stack de rendu en prenant cela en compte. En fait l'optimisation est une tache sans fin, on peut toujours faire mieux.
Pour ce qui est de ethumb, les travaux actuellement en cour dessus vont principalement impacter son API et tres peu ses performances. Les performances de cette bibliotheque viennent principalement de Evas et de Eet.
Nous avons plutot une TODO list qui devient maintenant plutot courte. Il reste principalement trois gros items dans celle-ci actuellement :
- finaliser la boite de dialogue de gestion du multi-ecran
- integrer et finaliser le nouveau theme
- rendre plus robuste le gestionnaire de fichiers
Ca nous fait esperer une release assez prochainement !
Hum, GDM ca compte ? Car avec systemd, il a commence a patcher GDM et la gestion du multi-seat. Si tu veux du multi-seat avec X.org, aujourd'hui, il te faut GDM et systemd... Donc d'une certaine maniere, c'est deja fait !
Donc on part sur une animation lente, va falloir garder les algo qui te font du lissage un peu intensif pour avoir un bon resultat. Je suis pret a te prendre le parie que tu distinguera difficilement la difference de resultat sur une aussi petite resolution.
Pour ce qui est la consommation CPU, la source est peu complexe, donc effectivement en vectoriel, tu dois pouvoir avoir des performances correct. En bitmap, l'effort de calcul est assez limite aussi, c'est juste 300 spans horizontaux, rien de bien sorcie. Compter une trentaine d'instructions par pixels, deux acces memoire en lecture et un en ecriture pour la complexite complete de l'operation, quelque soit le contenu de ton image.
Apres tu as un premier niveau d'optimisation, si le coeur de ton rectangle n'a pas d'alpha, on passe sur un algo de copy de pixels et non de blend. Resultat, un acces memoire en moins et quelques instructions de gagne. Enfin si ton rectangle est de couleur pleine, je ne fairais que les bordures avec une image, definissant le milieu comme vide et utiliserait un rectangle plein a la place. La, niveau perf, on sera au mieux dans la meme cour, voir si tu perds trop de temps dans la generation des bordures avec une tete d'avance pour le rendu bitmap (l'algo pour generer un rectangle plein sans alpha est trivial, juste un memset). Mais bon dans ton exemple avec un simple rectangle et un bon moteur vectoriel, je pense que tu dois reussir a pouvoir tenir la comparaison, mais si maintenant tu le remplis avec un gradient, ca ne sera plus le cas.
L'interet du rendu bitmap, c'est aussi que tu as moins de primitive a optimiser et donc que tu peux potentiellement faire plus d'effort de ce cote la.
Pour ce qui est du GPU, les spans, c'est un peu la premiere chose qu'un GPU sait faire, alors niveau optimisation, ta seule limite va etre la bande passante memoire a laquelle tu as acces. Pour ce qui est du vectoriel, tes performances vont vite avoir du mal, si les shader deviennent trop complique ou que en as trop, mais c'est sur, sur un rectangle, ca passera tres bien.
Sinon si le vectoriel etait si performant et si bien pourquoi veux-tu pouvoir generer un cache Bitmap et perdre de la memoire pour ca ? ;-)
Enfin pour les questions de souplesse faut-il encore que les bibliotheques qui gerent le vectoriel soit vraiment complete et fonctionne bien. Ce qui n'est pas le cas aujourd'hui. Donc ton artiste, il se limitera un peu par rapport a une image bitmap aux petits oignons... En plus, il y a une chose qui va etre embettant en vectoriel, si tu veux des images avec plus ou moins d'information en fonction de la resolution, tu fais comment ?
Quand un logiciel libre demarre bien et que tu as une communaute active qui contribue, le mainteneur peut se concentrer juste sur les morceaux les plus difficiles ou meme faire que du merge de patch. A un point, il peut meme passer la main a quelqu'un d'autre. Regarde Git et Linus ! Je pense que Lennart reussi tres bien a creer une communaute autour de ces creations et que cela l'aide a ne pas trop s'epparpiller !
[^] # Re: QT =>[]=>EFL
Posté par cedric . En réponse à la dépêche Tizen publie un SDK pré-alpha. Évalué à 6.
Mais pourquoi il faut toujours lier tout ca a Bada...
Chez Samsung, ils ont depuis 3 ou 4 ans, un OS Linux destine, d'abord, au marche Asiatique, SLP pour Samsung Linux Platform. Cet OS ayant ete developpe par Samsung dans le cadre du projet LiMo. Au tout debut, ils ont suivit le reste de la troupe LiMo et fait du GTK. Mais ils se sont rendu compte que ca ne marchait pas bien. Une experience a alors ete lance avec les EFL. Celle-ci, c'est revele tres pertinente, permettant d'avoir des applications reactives et avec le look attendu par les designers. Ils ont donc switche sur les EFL. Ce qui est tres amusant, car les EFL avaient ete considere rapidement au debut du projet LiMo, mais repousse, car ils voulaient une bibliotheque sous license LGPL et non BSD.
[^] # Re: "Concurrence libre" amusant!
Posté par cedric . En réponse au journal Vers un chamboulement du mobile. Évalué à 1.
J'aime beaucoup ce debat sur "ou est l'usine" ! Comme si la majorite de la plus value etait faite en usine. L'usine chinoise gagne 6.5$ par iPad, autant pour le "made in china".
Pour une lecture interressante sur la repartition du prix d'un iPad : http://www.objectifeco.com/economie/economie-politique/article/vincent-benard-produire-francais-un-marronnier-electoral-a-abattre-d-urgence
[^] # Re: Elixir
Posté par cedric . En réponse au journal J'ai free, j'essaie de comprendre. Évalué à 1.
Non, ca n'existait pas. Mais ca change rien au fait que tu aurais toujours pcre, la glib et mono. Soit toujours 4Mo de pris au minimum pour ca.
Chez moi, mscorlib, a elle seule, fait 2.5Mo.
Le runtime, tu veux le partager avec quoi ??? Il n'y a rien d'autre qui tourne ! Et sinon dans ton imagination, tu arrives a concevoir ce que c'est un jeu ? C'est 80% de data en memoire (son, image, ...). Quasiment rien en objet. La majorite des jeux vont jamais te prendre 3Mo pour des objets de ton langage. Par contre, pour tes graphismes et le son oui. Apres pour des benchmark, ou tu fais des calculs scientifique, c'est sur le JavaScript, c'est une bonne idee.
Pour le coup, je suis tres surpris. Vu comme ils sont super chiant avec les editeur de STB. Je me demande comment Microsoft a negocie son contrat et ce qu'il y a d'accessible comme contenu.
Different pays, different ayant droit, differente regles.
Pff, tu es desesperant. Je te demande une repartition entre les differents postes necessaire a la realisation du jeu. Et toi, tu fais juste une enveloppe global au pifometre. L'idee etait de te faire comprendre que le coup developpement sur des petits jeux comme Angry Bird ete quasiment exclusivement sur le game design, les graphismes, les niveaux, ... Mais ca a l'air d'etre complique de concevoir qu'il y a autre chose que du developpement en Mono...
Non, proprio n'est pas l'oppose de standard ! Mais c'est pas possible d'etre autant de mauvaise fois et d'essayer au tant de se rattraper a des branches pourries. Pour info, Opera est un logiciel PROPRIETAIRE qui respecte un STANDARD ! C'est deux concepts orthogonal !
Youhou ! Le store est vide parce que personne chez Free s'en occupe sur la v6. C'est tout. La solution SDL + OpenGL ES, marche tres bien. Pas la peine de demander a qui que ce soit de tout recoder pour tes beaux yeux !
Ca tu en parles a GameTree.TV. Rien a voir avec Free.
Faut arreter avec ton reve de cross plateforme. Les editeurs de jeux ont deja des solutions maisons ou du marche. Ils veulent un truc bas niveau qui marche et soit bien documente. Faut pas aller chercher midi a quatorze heure non plus.
[^] # Re: Elixir
Posté par cedric . En réponse au journal J'ai free, j'essaie de comprendre. Évalué à 1.
Non, 32Mo, c'est la v5. C'est un thread sur la v5 HD a la base... La v6 a environ 1Go de RAM a se partager entre le GPU, la decompression video et le systeme.
[^] # Re: Elixir
Posté par cedric . En réponse au journal J'ai free, j'essaie de comprendre. Évalué à 2.
Android pour TV n'existe toujours pas. Le NDK ne marche que sur ARM. Et il suffit de voir l'opinion de Logitech sur la question pour ce dire que c'est une bonne idee d'eviter Android sur une TV pendant encore quelque temps.
[^] # Re: Elixir
Posté par cedric . En réponse au journal J'ai free, j'essaie de comprendre. Évalué à 3.
Desole, pas le temps d'essayer de te retrouver les backups. Mais ce n'est pas difficile, tu fais un petit programme avec quelques sprites qui bougent en rebondissant sur l'ecran avec un fond d'ecran, et enfin un layer au dessus pour faire une bordure et un compteur de fps.
Alors juste comme ca, mais ta VM, il faut la mettre integralement en ram, sinon ca va provoquer des lags. La VM, c'est le coup minimal de toutes les applications que tu vas pouvoir faire. Certe tu as un coup par objet ensuite, mais le coup de ta VM quand tu as 32Mo, il n'est pas negligeable (Accessoirement ils augmentent le temps de chargement). Sinon chez moi, dans 4Mo, j'ai pcre, glib et mono, rien de plus.
M6 replay et Canalplay sont des offres de replay et non de VoD. La difference est sur les contraintes du contenu joue. Sur les offres de VoD, tu as des films et ils ont des regles de diffusion extrement stricte.
DLNA, c'est un truc de geek. C'est pas la mamie du cantale qui va jouer avec.
Non, elle se veut un equivalent a ce que propose un iPhone, du casual gaming. Elle est d'abord une interface tv. Ce n'est pas parce que ca se branche sur une TV et que ca affiche un jeu que c'est forcement adresse au meme public. La Xbox vise des gamers, des gens qui vont depenser de l'argent pour jouer. La Freebox, tout comme les TV et autres STB, s'addresse d'abord au grand public qui veut regarder la TV et avoir des services en plus sans trop depenser d'argent. D'ou aussi une difference de prix important entre les jeux que tu trouves sur Xbox et ceux que tu trouves sur Freebox TV.
C'est juste une detail finalement, la Xbox, c'est une set top box sans la TV... Et dire qu'a une epoque, une set top box n'etait sense faire que ca ! Mais sinon j'ai une chemine sous ma TV, c'est un succes planetaire depuis des siecles, preuve de son modele economique. Le market associe est un peu limite, mais ca n'a pas empeche des fournisseurs locaux de bois (apperement le kit de developpement est plutot dedie a des bucherons) de bien se developper...
C'est vrai, c'est tellement sur fait une TV qui affiche la TV. La preuve ma chemine, a part le fait qu'on ne peut pas regarder la TV avec, c'est comme une TV...
Non, l'environnement de dev est devenu coherent. Il ne l'etait pas au debut et a mis du temps a l'etre. Le cout de developpement ete tres eleve au debut.
Justement, le point est de te faire remarquer qu'il n'y a pas de regle general qui se resume a la technique dans le succes d'un projet.
Le market est bourre d'application pourri et inutilisable. Il faut vraiment faire un gros effort pour y trouver quelque chose de bien. Tu as un regard biaise sur le sujet. Mais a part les geek, android demotive beaucoup ses utilisateurs... Si je ne me trompe les stats de changement d'OS sont actuellement en faveur de l'iphone d'ailleur (plus de gens qui passe de android a iOS que l'inversement). Et les utilisateurs iOS depense plus que les utilisateurs Android dans leur store/market respectif.
Le plus gros frein du playbook, absence total d'utilisateurs. Tu rajoutes a ca une plate forme catastrophiquement lente et faut pas esperer grand chose forcement. Mais comme tu le fais remarquer, chaque store depend fondamentalement de l'environnement dans lequel il est. Tu veux absolument demontrer que la reussite ou l'echec d'un store est uniquement lie a la technique et tu en retiens que ce detail. Mais au final, meme dans ton exemple, le premier probleme, c'est quand meme l'absence d'utilisateur et la technique n'est qu'un second probleme.
Les exemples montrent clairement qu'il n'y a pas de regle universel, surtout technique, qui regissent la reussite ou l'echec d'un store. Chaque marche doit s'adapter a ses utilisateurs pour reussir.
Franchement, c'est quoi le cout de developpement d'apres toi d'une application comme Angry Bird ? Et la majorite des applications vendu sur smartphone et tablette aujourd'hui ? Tu repartis comment d'apres toi, les coups entre le developpement, le game design, les graphismes, les niveaux, le marketing. Et tu estimes que c'est quoi la plus grosse source de revenu pour ce jeu ?
Euh, le truc proprio, c'est toi qui parle de XNA, non ? Elixir et l'integralite de ses dependences sont libres et disponible. J'ai vraiment du mal a suivre ta pense quand tu utilises pas les bons mots pour decrire les concepts auquel tu penses.
Donc ta solution au probleme d'avoir un truc de trop haut niveau, c'est de proposer une autre solution de haut niveau. Je vois meme pas comment tu peux arriver a cette conclusion. Tu n'offres pas plus de liberte au gens ou alors a la marge. Sans compter que faire du dev avec Unity necessite d'avoir un paquet de designer pour arriver a produire un resultat correct.
Tout d'abord, je ne suis plus chez free depuis quelques mois. Pour repondre a ta question, il y a actuellement 3 SDK pour faire des jeux, Elixir, SDL + Open GL ES et Cedega.
Cedega est completement controle par une societe exterieur. C'est elle qui gere ses contrats et essayent de ramener des jeux sur sa plateforme qui se veut justement cross plateforme. Mais vu qu'ils sont dependant du processeur Atom, et qu'aucun autre FAI/constructeur de TV n'a choisit ce processeur, ils sont coince.
SDL + OpenGL ES a ete developpe pour permettre le portage quasi direct d'appli iPhone sur Freebox v6. C'est ce que fait GameLoft et leur difficulte de portage est uniquement sur le fait qu'il ne connaissait pas Linux au debut.
Maintenant qu'est-ce que tu veux attirer comme developpeur ? Quelque soit la solution, il faut, pour faire le developpement, etre en France. Tu te limites forcement au studio francais, car le genre de jeux dont on parle necessite bien plus que du dev, donc les independant auront forcement du mal. Etant donnee les nombres, de mon point de vue, il suffit de travailler en direct, sur le meme principe qu'avec GameLoft, d'avoir une gestion un peu plus subtile et sympatique du store pour que ca marche. Un SDK natif ouvert apportera au final peu de jeu nouveau de bonne qualite. Bien sur, cela permettrait d'avoir le portage des jeux libres dessus. Mais ils ne sont pas tres nombreux et si un developpeur s'en occupe a plein temps, en an, tous les jeux libres seront disponible sur la v6. En tout cas, c'est mon point de vue.
[^] # Re: Elixir
Posté par cedric . En réponse au journal J'ai free, j'essaie de comprendre. Évalué à 3.
J'ai arrete d'utiliser ce site, car les benchs sont mal ecrit et certain language utilise des facilites qui sont interdit a d'autre. Il n'y a aucune information de comparaison pertinente. De plus, la comparaison que tu pointes est faite sur V8 et non SpiderMonkey. Enfin, pour information, les EFL + Elixir + SpiderMonkey, ca prend 3Mo au complet avec toutes les dependences. Ce qui doit etre la taille de juste la VM mono sans aucune de ses dependences...
C'est bien, tu quote juste une partie de mon message. Si tu parles de la v5, c'est juste faux, si tu parles de la v6, alors oui, la surface d'attaque est superieur.
Je dois avoir loupe l'addition de A+B, parce que a part des grandes phrases sans aucun contenu technique ni prise en compte des contraintes, je n'ai rien vu. Et non, faire du natif, n'est absolument pas trivial contrairement a ce que tu as l'air de croire.
A+B n'est pas un argument technique. Tu me parles Java et Mono, je te dis pourquoi ces deux languages specifiquement ont ete elimine. Et oui, le Java existait avant le premier Pentium. Par contre, tu l'as deja utilise ? Parce que niveau temps d'initialisation, ressource consomme par la VM, je suis desole, mais ca fait 15 ans que je n'ai jamais trouve une seule application correcte et utilisable en Java.
Et concernant le : "on s'en fou", c'est juste que le seule effort qui vaudrait la peine serait d'utiliser un JIT JavaScript, qui donnerait des perfs plus interressante, mais l'effort necessaire vs le gain serait faible. Il y a d'autre chose a faire qui sont plus utile pour un tel projet. On vit dans un monde avec des contraintes physiques a prendre en compte, et cela impose de prioritise les choses pour maximiser le resultat obtenu.
Bon, ben, relis le post de depart alors. On parle de la Freebox HD, la v5, depuis le debut. C'est sur si on parle d'autre chose, on va pas avoir les meme conclusion. Deja sur la v6, tu n'as pas actuellement de SDK ouvert. Donc, je vois meme pas de quoi tu peux parler. Pour ce qui est du SDK natif, c'est du SDL + OpenGL ES en C/C++. Les contraintes de cette box, voir mon post precedent, sont totalement different. Le processeur fournit beaucoup plus de mode de securite. Il y a beaucoup plus de memoire (1Go). La ou le bas blaisse, c'est le GPU qui est pas top et necessite de bonne competence en OpenGL ES pour reussir a en tirer quelques choses. Mais globalement le rapport de puissance avec la v5, c'est un facteur 10. Ce n'est pas encore une console de jeu, mais tu as deja plus de liberter de developpement.
LOL ! J'avoue la, niveau credibilite, tu viens d'atteindre des sommets ! La XBox, c'est une console, c'est concu pour faire du Jeux. Ca se vend que comme ca, et ca ne vend que ca. Mais le materiel, ses capacites et son public n'ont rien a voir avec celui des TV ou des Set Top Box. Donc c'est juste pas le meme marche et ca n'a juste rien a voir. C'est une bonne idee de parler des consoles, mais c'est a cote de la plaque encore une fois.
Je pense que tu es tres porte sur la technologie et le developpement, mais tu manques de recul. Pour avoir un bon ratio cout de dev / revenus potentiels, les outils et le language ont assez peu d'importance.
Appel l'a demontre en lancant son Store avec un language ObjC que personne ne connaissait et un SDK qui marchait a l'epoque que sur les produit Apple. Par contre, ils avaient un bon travail de visibilite et le ratio offre / clients etaient tres bon au debut, ce qui a permit a quelques developpeurs de bien amortir leur developpement. Mais aujourd'hui developpez pour les produits Apple devient difficile et rapporte peu, trop de concurrence, peu de visibilite, croissance de la base de developpeur supperieur a celle des acheteurs d'applications. Conclusion les developpements qui marchent actuellement, ceux sont les applications pour les marques. Le reste rapporte marginalement et ne permet que difficilement pour les developpeurs independant de reussir.
Sur Android Market, le systeme est different. L'achat a l'acte est faible, le piratage eleve. Par contre, la publicite dans les applications rapporte, tous comme les achats in-apps. Il y a donc un interet de fond a faire des bonnes applications que les utilisateurs vont utilises longtemps pour que la publicite soit visible le plus longtemps possible. L'environnement de developpement d'Android et la difficulte de faire des tests sont faramineux sur cette plateforme morcele, mais si une application est bien faite alors elle peut rapporte gros et pendant longtemps.
De maniere generale, les outils sont secondaire si tu fournis un moyen aux developpeurs de s'y retrouver financierement. Faire plaisir a titi parce que sont language fetiche, c'est le C# et pas le Java ou si il prefere le Brainfuck, ne faira pas vendre plus d'application, si elles n'ont pas un modele economique valable.
Et cette lecon s'applique aussi a d'autre contexte, tu prend une Nintendo DS, la majorite des jeux ont fini pas etre des trucs pour gamine, parce que tout simplement c'etait les seuls a ne pas se faire pirater et a avoir un retour sur investissement correct. Ca n'a rien a voir avec la technique. Ca reste toujours une question de comment les developpeurs peuvent gagner de l'argent.
Sur les TV et les set top box, il n'y a encore eu tres peu d'inovation pour permettre aux developpeurs de rentabiliser leur developpement. Le modele economique est encore a creer et pour l'instant le Freestore n'apporte rien dans le domaine que ce soit en v5 ou v6 qui reponde a ce probleme. Peut-etre que l'arrive d'une nouvelle generation de Google TV ou d'une hypotetique Apple TV changera la donne, mais pour l'instant ca manque d'innovation pour creer un veritable eco-systeme rentable.
[^] # Re: Elixir
Posté par cedric . En réponse au journal J'ai free, j'essaie de comprendre. Évalué à 7.
Alors pour reprendre ta liste. Dalvik n'existait pas et le Java en general consomme trop de memoire. Meme probleme pour mono et le C#. Le SandBoxing d'application C++ demande un peu d'aide du CPU que tu n'as pas sur MIPS.
Et les contraintes d'Apple en terme de securite sont faible compare a celle d'une set top box. Il a ete possible sur certaine generation d'iPhone de mettre en place un jailbreak juste en allant sur une page web. Des chercheurs en securite, on demontrait qu'ils arrivaient a sortir facilement de la sandbox de l'iPhone depuis une application de l'Apple Store. Toutes ces failles de securite sont considere comme extremement grave sur une set top box et genererait l'arret immediat de tous les services de video a la demande et de TV. Les contraintes de securite ne sont absolument pas les meme !
De plus, penser que le JavaScript est la source d'une limitation des performances, c'est juste ne pas avoir la moindre idee du profil d'execution d'un jeu ou d'un logiciel. Tu passes plus de temps dans les routines graphiques et sons que dans la logique de ton jeu. Ce n'est pas donner l'ordre de deplacer un sprite qui prend du temps, mais bien celui de le dessiner a l'ecran qui va occuper la machine. Pour info, dans l'ensemble des jeux actuellement disponible, le plus gros consommateur de JS, occupe seulement 20% dans les routines lies au JavaScript. Certe ca serait plus sympa d'avoir un JIT et tu pourrais faire un peu plus, mais meme avec une multiplication par 10 des perfs du langage choisit, ca ne changera pas que tu ne pourras pas gagner sur les 80 autres pourcents ! Et sinon, tu sais de quelle epoque ca date le JavaScript ? D'une epoque ou la norme n'etait pas d'avoir chez soi mieux qu'un pentium 75 avec 64Mo de RAM. Ca correspond exactement au contrainte du materiel de la v5 (qui a plutot 32Mo de RAM). Et aujourd'hui ne t'en deplaise, le JavaScript voit ses VM evolue plus vite et obtenir plus d'amelioration que tout autre langage de script !
Donc dire que n'importe quel autre choix aurait ete plus judicieux, c'est juste n'avoir aucune idee des contraintes rencontre et du profil d'une application.
D'ailleur vu tes idees, OpenGL, Unity3D et XNA, je pense que tu n'as juste aucune idee de quoi tu parles ! La Freebox v5, c'est un MIPS a 200Mhz, avec 5 plans graphiques et un blitter. Tu peux meme pas decompresser des sons en hard, si tu veux pouvoir les mixer apres. Et toi, tu reves gentillement d'OpenGL et XNA...
Sur la V6, tu peux commencer a l'envisager, le processeur gere la virtualisation et le GPU fait de l'OpenGL ES, potentiellement meme de l'OpenGL. Mais sur la v5, c'est juste completement irrealiste ! Des fois, il y a des contraintes materielles a prendre en compte, la realite du monde physique, des choses comme ca. Avoir de grandes idees, c'est bien, mais realiser quelques choses qui marche, c'est mieux.
Pour repondre enfin a ta derniere question, il y a autant d'appli sur le Freestore que sur le magasin online subventionne de Samsung pour ses TV. Il n'y a pas d'autre market/store qui existe actuellement sur les TV. Meme Google et Apple n'en ont pas fait pour l'instant. Et non, ca ne se compare pas aux jeux sur portable, ni aux jeux en flash, car il faut forcement penser l'ergonomie d'un jeu pour la plateforme sur laquelle tu le vends, sinon il sera juste injouable !
Enfin, la taille du marche est aussi a compare au revenu potentiel et a la competition. Si tu es tout seul a faire un jeu et qu'il y a 4millions de clients, c'est mieux que si tu es 1millions a faire des jeux pour 300millions d'individu. La preuve en est, un bon jeu comme BounceBox developpe par un unique developpeur dans son coin a genere plus d'un million de parti.
Les problematiques sont plutot que pour qu'un store vive, il faut le gerer et pas le laisser s'auto gerer. Mettre en avant les jeux les plus reussi, nettoyer les applications trop pourri, permettre de tester avant d'acheter, fournir des teaser, des versions d'essais, mettre en place des mecanismes de promotion et plus de source de revenu potentiel pour un jeu ... En gros, si tu veux vendre, il faut mettre en avant le contenu, et pas juste faire un listing dans une interface mediocre. Croire que le probleme est au niveau de la technique te faira croire qu'en proposant juste un truc avec plus de technique tu resoudras le probleme. Mais si le Freestore sur la v6 n'est pas ameliore, le resultat ne sera pas meilleur, voir meme peut etre plus mauvais. Les difficultes du developpement natif en plus.
# Elixir
Posté par cedric . En réponse au journal J'ai free, j'essaie de comprendre. Évalué à 6.
Je vais te repondre juste concernant le SDK et ta question concernant la SDL. Tout d'abord, essaye de jouer a Doom et Duke Nukem 3D en mettant le .wad de doom ou les data necessaire de Duke Nukem sur le disque dur de ta Freebox HD. Tu vas tres vite te rendre compte que les performances ne sont pas enorme. Seul la resolution la plus basse est jouable.
SDL est un layer graphique simple a utiliser et qui n'offre aucune acceleration materiel correct. Resultat tous les jeux essayent avec leur moyen de faire un rendu graphique correct. Mais il n'y a pas grand monde capable de faire un pipeline de rendu optimise dans le monde du logiciel libre, resultat il a part Doom et Duke Nukem, il n'y a aucun autre jeu libre qui pourra passer.
Le second point a ne pas oublier, c'est les contrats avec les fournisseurs de contenu. Ceux-ci sont souvent fermement opposer a l'existence de code natif sur la meme machine et il y a une difficulte non negligeable a fournir un SDK natif utilisable sur l'architecture de la v5.
Tu prends ces deux points ensemble, et tu en conclus qu'il n'y a pas d'autre solution technique que d'utiliser les bibliotheques d'Enlightenment. Pour les autres toolkit, Qt faisant un OOM avant meme de pouvoir afficher quoi que ce soit, et GTK mettant 5min pour afficher une frame. Les ressources materiels disponible limite clairement les possibilites. Enfin le langage de script choisit, JavaScript, est actuellement le plus utilise et recoit une feroce competition entre Apple, Google, Microsoft et Mozilla. Donc le choix le plus perein dans le temps. Meme si aujourd'hui, j'aurais tendance a partir plutot sur v8 plutot que SpiderMonkey (mais ce dernier n'etait pas encore disponible a l'epoque pour MIPS).
PS: la sortie SPDIF doit permettre de sortir du 5.1, je dirais.
[^] # Re: Tizen / Mer
Posté par cedric . En réponse au journal L'avenir de Linux sur les smartphones ?. Évalué à 4.
En R&D, c'est effectivement legerement different. Il y a des efforts dans tous les sens pour tenter des trucs, des fois, ca marche, des fois, ca marche pas. C'est le cas pour je pense toutes les societes qui font de la R&D.
Mais a ma connaissance, Tizen n'est plus un projet de R&D, et c'est l'equipe en charge du projet SLP Enlightenment qui est aussi en charge de fournir, ce qu'on appel Tizen. Et etant donnee les delais, moins de 6 mois pour faire un terminal mobile, tu peux etre sur qu'ils ne partiront pas from scratch.
La raison de la communication sur HTML etant a mon avis plus une volonte de rassurer les operateurs et de surfer sur le buzzword du moment. Plutot qu'une raison technique. Il n'y a qu'a regarder ce qu'est WAC pour se dire qu'on ne peut pas faire rapidement quoi que ce soit de serieux avec.
Et oui, j'ai evite de parler du centre de R&D de Londres, car je ne connais pas leurs activites pour l'instant. Ils ont aussi un centre de R&D en Pologne, je crois, ou dans un pays proche, qui a fait pas mal de devs Linux bas niveau et noyaux. Mais cela sans etre lie au projet SLP a ma connaissance. C'est une tres grosse societe, donc la vue et les informations sont forcement partielles. Je ne connais que le travail d'une partie de l'equipe SLP Enlightenment et ca fait deja un paquet de monde. Samsung m'ayant sponsorise pour l'amelioration des performances du rendu video dans le canvas des EFL de juin a octobre. L'ensemble des developpements etant entierement libre et completement integre des le depart upstream.
[^] # Re: Tizen / Mer
Posté par cedric . En réponse au journal L'avenir de Linux sur les smartphones ?. Évalué à 2.
Vu la taille de la societe, annoncer que 90% de leur projet sont jete, ca serait juste faramineux ! Je ne sais pas dans quelle branche de Samsung, tu as travaille, mais elles sont toute construite de maniere independante et en competition. Leur management est different et leurs objectifs aussi. Il n'est pas possible de comparer la branche Android a la branche Windows Phone ou Bada ou SLP.
Celle qui nous interresse ici, c'est la branche SLP qui a depuis longtemps migre tous ses efforts sur Enlightenment et laisse tomber GTK+ pour des problemes de perf. Ils commencent a avoir une bonne comprehension de ce qu'est le logiciel libre. Il y a encore du travail, mais ca evolu dans la bonne direction pour l'instant. Il est vrai qu'on est, tant que le logiciel et un device ne sont pas libere, dependant de decision de manager, mais ils ont encore le droit au benefice du doute.
De plus et a ma connaissance, personne en France ne travaille chez Samsung sur le projet SLP pour l'instant. Leur R&D se trouvant principalement en Israel et en Coree (Ils doivent aimer vivre dangereusement...).
[^] # Re: Tizen / Mer
Posté par cedric . En réponse au journal L'avenir de Linux sur les smartphones ?. Évalué à 4.
Tout simplement parce qu'il faut verifier que tous les morceaux de code ont les bonnes licenses et peuvent etre publie. Samsung doit verifier qu'il a bien les droits de publication de tout le code et les morceaux qui manquent doivent soit etre recoder soit etre renegocier.
Intel arrive derriere pour s'assurer qu'ils ont un systeme qu'il build correctement et que l'ensemble marche comme attendu. En fait, le developpement a deja eu lieu, Intel a juste convaincu Samsung d'en faire une plateforme de developpement ouverte. Donc la problematique n'est pas de faire le dev derriere des portes closes, mais d'ouvrir ces portes.
[^] # Re: Tizen / Mer
Posté par cedric . En réponse au journal L'avenir de Linux sur les smartphones ?. Évalué à 10.
Actuellement le seul terminal annonce avec un avenir, c'est Tizen, le reste c'est juste du truc de geek qui n'ira jamais plus loin qu'une rom pour afficionado dans leur coin. Dis comme ca, c'est clairement violent, mais il faut etre realiste, sans un terminal et une societe avec les moyens de le marketer, ca ne donnera rien de credible.
Pour ce qui est de Tizen, l'annonce a ete clairement fait trop tot. Il n'y avait aucune urgence a communiquer sur le sujet avant que le code source soit libere. Et comme ca ne se fait pas en 5 min, et bien, on se retrouve dans une situation ou on a l'impression d'avoir du vaporware. Sauf que le terminal Tizen, il existe bien et il y a une bonne centaine d'ingenieur qui travail dessus chez Samsung dans le but d'en faire un produit grand public et utilisable.
Maemo, Harmattan et Meego sont mort suite au decision de Nokia. En fait, Meego est mort le jour ou Nokia a decide que l'interface utilisateur ne serait pas libre. Cela a fait de meego, yet another distribution. Avec toutes les difficultes qu'il y a a creer du logiciel embarquer rapide, fiable et utilisable, ils ont rajoute la difficulte de maintenir leur propre distribution. Enfin, il y a un autre probleme avec Meego, c'est Qt qui est vu par tous les industriels des telecoms comme etant une technologie controle par Nokia. Alors forcement, le destin de ces systemes sont completement lie a Nokia, si ont un jour avoir un produit grand public.
Si on prend tout ca en compte, on comprend mieux une parti de la communication autour de Tizen. Le choix de HTML, une technologie que personne controle, mais que tout le monde connais. Le choix de se baser sur LiMo, un consortium d'industriel des telecoms. Le choix de partir sur la version de Samsung, SLP, qui fonctionne deja et a une stack logiciel complete pour l'embarque. Alors oui, l'avenir d'un device est lie au decision de Samsung, aujourd'hui. Oui, tant que le code n'est pas ouvert, on ne peut rien dire. Mais clairement, il y a eu une prise en compte des erreurs passees jusqu'a maintenant. Et si il release l'integralite de Tizen, UI compris, alors oui, ils demontreront qu'ils ont pris en compte l'histoire. Samsung n'est pas Nokia, et pour l'instant, on peut leur laisser le benefice du doute.
A l'heure actuelle seul Intel et Samsung travaille sur Tizen pour en preparer sa release. C'est un travail important et qui ne peut se faire que derriere des portes closes. Il est donc normal qu'aucune contribution externe n'est lieu pour l'instant et que les developpeurs independant prennent ca pour du vaporware. Mais ca n'empeche que le code et le terminal existe deja :-) Il faut donc prendre un peu tout ca avec du recul et analyser la situation sans prendre en compte sa propre frustration de ne pas encore avoir un telephone vraiment libre et cool de disponible !
[^] # Re: c'est lui qui l'a lancé, cette pétition ?
Posté par cedric . En réponse au journal Trolldi 2 : une pétition anti-Lennart. Évalué à 3.
La resistance au changement, le manque de diplomatie et le fait que ca rajoute du travail a des equipes qui ont deja du mal a fournir un systeme competitif face a Linux. Juste des idees comme ca...
[^] # Re: C'est ça le libre ?
Posté par cedric . En réponse au journal Trolldi 2 : une pétition anti-Lennart. Évalué à 2.
C'est a dire ?
# Revue de code et bug tracker
Posté par cedric . En réponse à la dépêche Hébergez vos projets avec Gitlab. Évalué à 1.
Tous ces projets autour de git sont tres interressant. Trac etait bien, mais il mettait une barriere a l'entree plus eleve pour les nouveaux contributeurs. Envoyer un patch ete complique, alors qu'avec git et les merge request, participer a un projet devient trivial.
C'est la ou les outils de revue de code deviennent tres important, gittorious et github permettent de faire des commentaires par ligne de code, est-ce gitlab le permet ? Il est aussi possible de noter un patch et quand celui-ci passe une limite, il est automatiquement merge upstream, est-ce que gitlab le permet ?
Sinon avec svn et trac, on pouvait automatiser la fermeture d'un bug lors d'un commit. Est-ce que c'est possible de faire de meme avec git et gitlab ?
Sinon le truc que je trouve tres domage avec en tout cas gittorious, c'est qu'il est absolument pas possible de retrouver les commentaires d'un patch une fois que celui-ci a ete applique upstream via la ligne de commande. Ca serait tellement plus sympa de pouvoir les obtenir lors d'un git log.
Et de maniere symetrique, c'est domage qu'on ne puisse pas faire de la revue de code ou de la resolution de bug offline. Ca serait tellement puissant si on pouvait faire tout ca offline, recuperer par un git pull toutes les merge request, etudier chaque serie de patch, faire des annotations, tester la compilation et le resultat, puis une fois fini, pousser les commentaires et la note du merge request. Pour pas mal de developpeur, un outil web est nettement moins efficace que la ligne de commande...
[^] # Re: RAD?
Posté par cedric . En réponse à la dépêche Sortie des EFL 1.1.0. Évalué à 3.
Le probleme sur lequel tu mets le doigt, c'est surtout qu'on n'a pas d'outil dedie aux designers, ergonome et graphiste pour faire un theme et qu'ils sont donc oblige d'avoir des methodes de developpements. C'est a dire de passer par un simple editeur de texte, compiler le theme, le tester, detecter les problemes et recommencer. Pas tres efficace, pas tres visuel et effectivement loin de leur pratique habituel.
Ensuite pour repondre a ton message precedent, effectivement E17 contient pas mal de code ecrit depuis des annees qu'on n'a pas envie de toucher tout de suite. Entre autre exemple, les boites de configuration ne sont pas decrit en Edje, donc on ne peut pas en changer leur layout facilement. E17 n'utilise pas Elementary. Mais a un moment donne, si on veut faire une release, il a fallu faire le choix de mettre en standby ces changements et ameliorations.
[^] # Re: RAD?
Posté par cedric . En réponse à la dépêche Sortie des EFL 1.1.0. Évalué à 3.
Avec les EFL, c'est juste un changement de theme. Tous n'est pas techniquement operationnel aujourd'hui pour ca, mais les bases sont la. La premiere chose a bien comprendre, c'est la separation claire entre logique et interface grace a Edje. Cela veut dire que tu peux changer toutes l'interface en changeant juste le theme. Le theme est en charge du layout. Il peut te creer tes listes, tes boutons, definir leur deplacement et transition. Donc oui, le theme defini l'ergonomie de ton application dans le monde des EFL et pas uniquement une image dans un coin ou la couleur de la font.
Biensur, il y a des choses qui sont fondamentalement different entre tous les terminaux. En premier lieu, la precision du pointeur (taille du doigt sur un touchscreen vs souris) et ensuite le dpi qui fait qu'une font va etre lisible ou non. Cela implique des regles strictes quand a la maniere de redimensionner les objets a l'ecran. Ceux sont des contraintes fournit par le profile du terminal et pris en compte automatiquement par les EFL. Enfin le dernier point et que tu souleves avec raison, c'est l'interactivite, l'exemple type, c'est une liste vertical dont on espere qu'elle sera "kinetic" sur un touchscreen et classic avec une barre de navigation sur un desktop. Tu peux rajouter la navigation entre les widgets a l'aide de la touche Tab (Desktop) ou d'une croix directionnel + entre (TV et Set Top Box). Mais cela aussi fait partie du profile. Au final, cela reste un comportement gerable principalement dans le toolkit graphique via un profil.
Donc l'ergonomie d'une application peut etre juste gere par le theme et le profile de notre point de vue et c'est ce vers quoi l'on tend.
QtQuick/QML n'est pas comparable avec ceux dont on parle dans les EFL, car il ne gere pas tout ce que je viens de decrire automatiquement et il faut rajouter cette logique dans le QML. En fait, c'est un defaut de conception inherent a cette technologie, il est necessaire de mettre de la logique de ce cote la. Cela donne plus de souplesse et permet de rapidement faire des prototypes, mais avec le temps se pose des difficultes de maintenance et de performance.
[^] # Re: RAD?
Posté par cedric . En réponse à la dépêche Sortie des EFL 1.1.0. Évalué à 2.
Parce que ta version Qt pour telephone est completement differente de ta version pour Desktop aussi peut etre. En tout cas, les widgets disponibles sur N9 n'ont rien a voir avec ce que tu peux avoir sur Desktop.
Enfin avec les EFL, la problematique sur Desktop, c'est juste une histoire de theme et de profile. Pas franchement de code. En fait, en se focalisant sur de l'embarque riche, on fonctionne par defaut sur n'importe quel desktop. La demarche inverse n'etant pas vrai. Et on parle d'embarque riche ici, c'est a dire que l'on veut avoir les meme fonctionnalites que sur un desktop lourd.
En fait, si tu n'as pas remarque la plus part des tablettes/telephones commencent a etre livre avec une sortie hdmi et un port usb hote. L'objectif, c'est que tu lances exactement la meme appli, exactement le meme code, mais que le theme et le profile soit different par ecran. Et ton appli s'adapte directement a l'ecran en fonction de son type, tv, ecran pc ou video projecteur. Je te laisse imaginer toutes les implications de ce genre d'idee et ce que tu peux en faire. Mais c'est ce sur quoi on travaille et c'est ca l'objectif de faire une bibliotheque pour l'embarque, que tu n'es plus besoin de ton desktop actuel.
[^] # Re: RAD?
Posté par cedric . En réponse à la dépêche Sortie des EFL 1.1.0. Évalué à 4.
Malheureusement non. C'est le point qui peche le plus. On a des trucs dans les cartons, mais rien de reelement concret/utilisable. Cela deviendra surement la priorite apres la release de E17.
[^] # Re: E17 - un simple colorant de fenêtres ou un emulsifiant d'expérience utilisateur
Posté par cedric . En réponse à la dépêche Sortie des EFL 1.1.0. Évalué à 3.
Peut-etre parce qu'une fois qu'on a optimise quelque chose, son profil change et donc que l'on peut optimiser quelque chose d'autre. Il y a aussi le contexte materiel qui evolue. Aujourd'hui on est partie pour avoir du multi-coeur dans tous les environnements. Il devient donc interressant d'optimiser la stack de rendu en prenant cela en compte. En fait l'optimisation est une tache sans fin, on peut toujours faire mieux.
Pour ce qui est de ethumb, les travaux actuellement en cour dessus vont principalement impacter son API et tres peu ses performances. Les performances de cette bibliotheque viennent principalement de Evas et de Eet.
[^] # Re: la suite ?
Posté par cedric . En réponse à la dépêche Sortie des EFL 1.1.0. Évalué à 10.
Nous avons plutot une TODO list qui devient maintenant plutot courte. Il reste principalement trois gros items dans celle-ci actuellement :
- finaliser la boite de dialogue de gestion du multi-ecran
- integrer et finaliser le nouveau theme
- rendre plus robuste le gestionnaire de fichiers
Ca nous fait esperer une release assez prochainement !
[^] # Re: Syndrome de la compatibilité ascendante
Posté par cedric . En réponse au journal Que faut-il penser de Lennart qui casse tout ?. Évalué à 1.
Hum, GDM ca compte ? Car avec systemd, il a commence a patcher GDM et la gestion du multi-seat. Si tu veux du multi-seat avec X.org, aujourd'hui, il te faut GDM et systemd... Donc d'une certaine maniere, c'est deja fait !
[^] # Re: Dommage que la dépêche soit un peu courte
Posté par cedric . En réponse à la dépêche EFL 1.1 alpha. Évalué à 3.
Donc on part sur une animation lente, va falloir garder les algo qui te font du lissage un peu intensif pour avoir un bon resultat. Je suis pret a te prendre le parie que tu distinguera difficilement la difference de resultat sur une aussi petite resolution.
Pour ce qui est la consommation CPU, la source est peu complexe, donc effectivement en vectoriel, tu dois pouvoir avoir des performances correct. En bitmap, l'effort de calcul est assez limite aussi, c'est juste 300 spans horizontaux, rien de bien sorcie. Compter une trentaine d'instructions par pixels, deux acces memoire en lecture et un en ecriture pour la complexite complete de l'operation, quelque soit le contenu de ton image.
Apres tu as un premier niveau d'optimisation, si le coeur de ton rectangle n'a pas d'alpha, on passe sur un algo de copy de pixels et non de blend. Resultat, un acces memoire en moins et quelques instructions de gagne. Enfin si ton rectangle est de couleur pleine, je ne fairais que les bordures avec une image, definissant le milieu comme vide et utiliserait un rectangle plein a la place. La, niveau perf, on sera au mieux dans la meme cour, voir si tu perds trop de temps dans la generation des bordures avec une tete d'avance pour le rendu bitmap (l'algo pour generer un rectangle plein sans alpha est trivial, juste un memset). Mais bon dans ton exemple avec un simple rectangle et un bon moteur vectoriel, je pense que tu dois reussir a pouvoir tenir la comparaison, mais si maintenant tu le remplis avec un gradient, ca ne sera plus le cas.
L'interet du rendu bitmap, c'est aussi que tu as moins de primitive a optimiser et donc que tu peux potentiellement faire plus d'effort de ce cote la.
Pour ce qui est du GPU, les spans, c'est un peu la premiere chose qu'un GPU sait faire, alors niveau optimisation, ta seule limite va etre la bande passante memoire a laquelle tu as acces. Pour ce qui est du vectoriel, tes performances vont vite avoir du mal, si les shader deviennent trop complique ou que en as trop, mais c'est sur, sur un rectangle, ca passera tres bien.
Sinon si le vectoriel etait si performant et si bien pourquoi veux-tu pouvoir generer un cache Bitmap et perdre de la memoire pour ca ? ;-)
Enfin pour les questions de souplesse faut-il encore que les bibliotheques qui gerent le vectoriel soit vraiment complete et fonctionne bien. Ce qui n'est pas le cas aujourd'hui. Donc ton artiste, il se limitera un peu par rapport a une image bitmap aux petits oignons... En plus, il y a une chose qui va etre embettant en vectoriel, si tu veux des images avec plus ou moins d'information en fonction de la resolution, tu fais comment ?
[^] # Re: éparpillement
Posté par cedric . En réponse au journal Lennart casse les logs!. Évalué à 2.
Quand un logiciel libre demarre bien et que tu as une communaute active qui contribue, le mainteneur peut se concentrer juste sur les morceaux les plus difficiles ou meme faire que du merge de patch. A un point, il peut meme passer la main a quelqu'un d'autre. Regarde Git et Linus ! Je pense que Lennart reussi tres bien a creer une communaute autour de ces creations et que cela l'aide a ne pas trop s'epparpiller !