Je préfère avoir un partenariat qui permet de gagner de l'argent et de payer des devs pour améliorer un logiciel que d'avoir des logiciels libres à la traine par rapport à leurs équivalents propriétaires.
Ça n'est pas à proprement parler de la publicité. Sauf si tu considère comme publicité le fait de faire utiliser à des gens quelque chose que la plupart d'entre eux utiliseraient de toute façon.
5 acteurs (Mozilla, Google, Apple, Microsoft, Opera), font 5 moteurs Javascript qui sont tous extrêmement performant. Je crois qu'il n'y a pas d'autres langages qui peuvent se targuer d'avoir 5 implémentations (dont 3 open-sources) rivalisant pour les performances, avec plusieurs dizaines de personnes qui travaillent sur chaque moteur à plein temps.
Pour être un peu plus sérieux, certaines personnes ont eu de bon résultats avec des jeux video 3D complets en javascript (cross-compilés depuis C ou pas), des codecs audio (pas encore video). D'autres exemples sur baddassjs 1.
Notre système d'exploitation pour téléphone est multi-tâche, et l'a été depuis sa création. Je te parle de plusieurs processus (au sens UNIX) distinct, et d'une manière pour l'utilisateur de les ouvrir, de les fermer et de passer de l'un à l'autre.
Point rendu caduc par la réponse au 1. Il faut se rendre compte que Javascript/HTML n'est pas vraiment différent d'une autre technologie de création d'interface graphique, c'est un runtime tout à fait classique, mais qui sandbox tout. D'après les personnes que je côtoie, faire une application utilisant des technologies web serait plus rapide que de faire l'équivalent avec du code natif (Je ne sais pas vraiment, je fais du C++ dans le moteur de Firefox, très rarement du front). La plupart du temps (i.e. il y à beaucoup de cas très valides pour utiliser du code natif), une application réalisée avec des technologies web fera le boulot tout aussi bien qu'une application écrite en code natif.
Tu peux utiliser ce qu'il te plait. La target de compilation sera javascript, mais nombre de personnes utilisent (par exemple) du C cross compilé vers un sous ensemble de javascript qui se JIT très bien. Les performance sont très haute (environ deux fois plus lent que du C compilé avec clang en -O2). Je te laisse lire la FAQ1, et t'invite à poser des question si tu doutes de la pertinence de ce choix. Certaines personnes utilisent d'autres langages, crées de toutes pièces (Coffeescript), ou pas (Python). La plupart des développeurs d'application utilisent toutefois Javascript. J'ai personnellement un problème avec le fait que Javascript soit non typé, et emscripten est une bonne solution.
C'est un troll, mais pour être honnête, tu ne trouveras jamais de publicité sur un site Mozilla, et nous ne prenons (ni prendrons) pas en charge les DRM. Je t'invite à t'inscrire sur la mailing w3c 2 à ce sujet là, tu as l'air d'être de notre côté.
Je pensais plutôt à une lecture directe du framebuffer et de la sortie audio, qui aurait l'avantage d'être sans perte. On pourrait même imaginer utiliser xvfb et un device virtuel audio pour éviter de monopoliser un écran / faire du bruit.
Qu'on le veuille où non, Javascript est facilement le langage de script le plus rapide qui existe (je t'encourage à aller regarder ce qu'il se passe du côté de asm.js), et le seul qui est dispo dans les navigateurs. D'autant plus que, par rapport à un plugin binaire flash que nous (Mozilla) ne contrôlons pas, implémenter flash au dessus de js est très bon par rapport à la sécurité (je ne dis pas que Firefox n'a pas de problème de sécu, je dis qu'il en a beaucoup beaucoup moins que flash, et qu'on patch/distribue Firefox bien plus vite).
Alors nous, dans chez Mozilla, on aime pas bien les DRM (surprise!).
Par contre, on aime pas vraiment que le web soit non-compétitif par rapport au natif (bon, alors quand on recontextualise, cette phrase pourrait vouloir dire que le web est moins bien que le natif parce que c'est plus facile de faire du DRM avec du code natif, et là, du coup, ahem).
Du coup, on est en train d'implémenter la specification "Media Source Extensions" 1, pour que les gens puisse gérer leur buffering à la main, insérer des pubs (on peut être d'accord où pas d'accord avec ça, mais les fournisseurs de contenus en ont besoin. Perso, je préfère payer pour mon contenu, mais tout le monde n'est pas de mon avis), faire du time shifting, de l'édition vidéo, et du streaming adaptatif (on pourra faire plein d'autre chose avec, c'est que des exemples). À priori, puisqu'on aura un contrôle assez bas niveau, on pourra implémenter des DRM avec. Notez qu'en fait, ça sera assez trivial pour quelqu'un qui sait appliquer un patch et compiler un programme de récupérer le flux brut (un peu comme avec tous les systèmes de DRM, en fait, mais ça, les ayant droits n'ont pas encore bien compris).
Nous, ça nous sert principalement à faire Shumway [2], une VM flash écrite en Javascript. Quand on aura cette API, on pourra lancer (par exemple), le lecteur flash d'un site qui n'est pas passé à HTML5, sans avoir le plugin binaire (proprio ou pas) flash. Ce qui est, à mon avis complètement biaisé, une bonne chose.
Autant vous dire qu'on va essayer de se battre pour éviter au maximum d'avoir des DRM dans le web, mais qu'il y a deux-trois boites dans le secteur pas forcément de notre avis.
Le téléphone à bien 512Mo de RAM, mais le kernel est trafiqué pour n'en utiliser 190Mo environ, afin de pouvoir être certain de pouvoir faire tourner la chose sur des configuration modestes (et donc peu onéreuses).
Il te faudrait:
- Une ROM ICS
- De grosses compétences en C et en programmation noyau pour faire/porter des drivers
- De bonnes grosses compétences en Gecko pour faire des workarounds pour les bugs desdits drivers
- Que le GPU soit assez bien
C'est faux de dire qu'Android tourne sans ralentissement dessus. Une phrase du type "Android 2.3 tourne de manière utilisable dessus" serait déjà plus correcte. Les nombreux tests/revues que tu peux trouver sur internet sont formels, c'est pas cher, ça fait le job, mais ça tourne pas du tout sans ralentissement (OOM killer à foison, saisie de texte non fluide, pas à 60fps tout le temps, etc.).
Firefox OS non plus ne tourne pas sans ralentissement sur cet appareil, d'ailleurs.
Parce qu'il y a beaucoup de gens (je parle des nombreux développeurs qui font du web) qui sont très heureux de pas avoir à apprendre un nouveau langage, des framework, des IDE et plein d'autres choses pour faire des applications. Aussi, tu deviens cross-platform/device facilement, tu as pas mal de sécu qui est géré pour toi. Les gens qui n'aiment pas ça pourront aller voir d'autre plateformes qui leur plairont plus, je suppose.
Perso, j'aime beaucoup le C, et j'ai aucun souci pour faire plein de trucs avec, mais la plupart des gens n'ont pas envie de se frapper des segfaults ou de la manipulation de mémoire manuelle pour faire leurs applications mobiles.
Et aussi, on est Mozilla, et on aime bien le web et on pense sincèrement que c'est une technologie viable pour les mobiles, qui nous sortirait des environnements non-compatibles de la concurrence.
À un moment on faisait comme ça, mais plus maintenant, je sais plus pourquoi. Enfin, pour être précis, et si tu as regardé les slides, on pouvait configurer ce qu'on appelle les permissions implicites, pour autoriser une appli à faire un truc, dans les settings. Mais plus maintenant, je sais pas pourquoi (on arrive aux limites de ce que je sais sur FirefoxOS, je bosse pas dessus au jour le jour).
Une sorte de "mode développeur" est une chose vraiment importante à avoir, et on s'en est rendu compte lors de ces App Days (pas qu'on ne le savait pas, mais on pensait pas que c'était autant handicapant). On a proposé des hacks aux gens pour qu'ils puissent bosser, mais il me semble qu'une personne a quelque chose de plus générique, ça devrait arriver bientôt.
Dans cette phrase on parle d'applications, via un store, est ce que dans un des cartons de ces merveilles il y aurait la même idée de packaging, mais pour un site web au sens plus classique du terme.
Oui, c'est la beauté des OpenWebApp. Tu peux simplement avoir un site web, qui dispose d'un fichier "manifest.webapp", et hop, ça te fait une application. Tu peux aussi proposer un zip, ou envoyer ton app sur le store. Tu peux aussi créer ton propre store.
L'avantage d'aller sur le store Mozilla, pour l'instant, c'est que c'est le seul qui peut faire des revues de code, et donc accorder des permissions avancées aux applications.
Je pense que tu serais interessé par les slides de julienw 1, qui expliquent comment appcache fonctionne, appcache étant la technologie qui gère la persistence des assets dans les navigateurs, et qui est très utilisé dans Firefox OS.
Un des buts du projet est de montrer que la plateform Web est tout à fait capable de rivaliser avec les applications natives pour la plupart des applications (bien évidemment pas toutes, on manque de temps et il faut faire des choix si on veut sortir un truc un jour).
Si tu veux écrire une application mais que tu ne peux pas, de mon point de vue, c'est qu'il faudrait qu'on expose une API pour te laisser écrire ton programme.
Sur les autres OS mobiles, de la même manière, tu n'es pas root (bien que dans certains cas, tu puisses le devenir, les utilisateurs de ton application ne le seront pas par défaut), des fois tu n'as pas accès au FS, et tu es fortement encouragé à passer par leurs API. Mais avec le temps, toutes les API nécessaires sont disponibles.
Tu peux tout à fait, par contre, tester ce que tu veux: il est relativement aisé d'écrire une API dans Gecko, flasher ton propre build, pour peu que tu te renseignes un peu avant et que tu aimes bien parler sur IRC (peu de gens refuseront de t'aider, et encore, ça serait probablement par manque de temps). Tu auras alors du levier pour convaincre les personnes d'investir leur temps dans ton API (pour faire des revues de code, nécessaire pour faire rentrer un patch, ou des revues de sécurité, etc.).
Un OS correct ne se fait pas en un jour, et c'est tout à fait avec des cas d'utilisations qu'on avait pas prévu qu'on fera quelque chose de qualité.
Je pense qu'un lecteur pourrait croire qu'IonMonkey est utilisé dans Firefox OS. Il n'en est rien. En effet, IonMonkey dépend d'une autre fonctionnalité des moteurs javascript présent dans Firefox, appelée Type Inference (TI, pour inférence de types). TI est monolithique, cela voulant dire qu'on ne peut l'activer que pour une programme, pas pour, disons, une fonction d'un programme Javascript. L'empreinte mémoire est alors vraiment importante, et la mémoire disponible sur les téléphones visées (qui ont 256Mo de ram, un peu plus d'une centaine disponible pour les programmes utilisateurs) est trop faible.
L'équipe Javascript travaille aussi à augmenter les performances, avec un autre projet qui fonctionnera à priori sur Firefox OS (mais qui améliorera aussi les performances sur desktop et android), en écrivant un baseline compiler. Comme toujours, on peut suivre l'avancement de ce projet sur le bug 805241 1.
Tu peux desactiver WebGL dans Gecko (via une pref). Je recommande chaudement de ne pas le faire, WebGL peut avoir bon nombre de cas d'utilisation dans des applications qui n'utilisent pas la 3d, pour accelérer le dessin. Oui, je suis d'accord, Gecko devrait le faire tout seul et c'est un hack (qu'on évite d'utiliser dans Gaia), mais en attendant qu'on optimise notre pipeline pour tous les cas d'utilisation possible et inimaginable de html css et js (autant dire que ça fait pas mal), c'est une optimisation possible.
Non, les téléphones que vous avez eu entre les mains n'étaient pas des Peak. En comparaison, les Peaks auront un CPU double coeur dont la fréquence sera 1.5 fois plus élevée (800MHz et un seul coeur pour le modèle de ce weekend). Le Peak disposera de 512Mo de RAM (contre 256 pour le téléphone de ce weekend), et d'un GPU vraisemblablement bien plus véloce (nécessaire puisque l'écran sera beaucoup plus grand et la résolution bien plus élevée).
Je pense qu'on peut comparer les téléphones de ce weekend (un ZTE Kis) à un téléphone Android d'il y a deux ou trois ans, en terme de matériel. La réactivité vient pour une grande partie du fait que l'équipe en charge du rendu graphique ("gfx") a su tirer parti du GPU du téléphone. Il est relativement peu puissant, mais fait toute la différence.
Les appareils Geeksphone ne seront disponibles qu'en février, et nous même les développeurs Mozilla n'y avons pas accès pour le moment.
[^] # Re: Dans Firefox
Posté par padenot . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 4.
Je préfère avoir un partenariat qui permet de gagner de l'argent et de payer des devs pour améliorer un logiciel que d'avoir des logiciels libres à la traine par rapport à leurs équivalents propriétaires.
Ça n'est pas à proprement parler de la publicité. Sauf si tu considère comme publicité le fait de faire utiliser à des gens quelque chose que la plupart d'entre eux utiliseraient de toute façon.
[^] # Re: Dans Firefox
Posté par padenot . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 7.
5 acteurs (Mozilla, Google, Apple, Microsoft, Opera), font 5 moteurs Javascript qui sont tous extrêmement performant. Je crois qu'il n'y a pas d'autres langages qui peuvent se targuer d'avoir 5 implémentations (dont 3 open-sources) rivalisant pour les performances, avec plusieurs dizaines de personnes qui travaillent sur chaque moteur à plein temps.
[^] # Re: Dans Firefox
Posté par padenot . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 2.
Heh :-)
Pour être un peu plus sérieux, certaines personnes ont eu de bon résultats avec des jeux video 3D complets en javascript (cross-compilés depuis C ou pas), des codecs audio (pas encore video). D'autres exemples sur baddassjs 1.
[^] # Re: Dans Firefox
Posté par padenot . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 9.
[^] # Re: Dans Firefox
Posté par padenot . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 10.
Comme le dit très justement quelqu'un plus haut, le problème principal de flash, c'est l'augmentation de la surface d'attaque.
Implémenter flash (ou pdf) en javascript permet de ne pas augmenter la surface d'attaque.
[^] # Re: Dans Firefox
Posté par padenot . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 3.
Je pensais plutôt à une lecture directe du framebuffer et de la sortie audio, qui aurait l'avantage d'être sans perte. On pourrait même imaginer utiliser xvfb et un device virtuel audio pour éviter de monopoliser un écran / faire du bruit.
[^] # Re: Dans Firefox
Posté par padenot . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 4.
Qu'on le veuille où non, Javascript est facilement le langage de script le plus rapide qui existe (je t'encourage à aller regarder ce qu'il se passe du côté de asm.js), et le seul qui est dispo dans les navigateurs. D'autant plus que, par rapport à un plugin binaire flash que nous (Mozilla) ne contrôlons pas, implémenter flash au dessus de js est très bon par rapport à la sécurité (je ne dis pas que Firefox n'a pas de problème de sécu, je dis qu'il en a beaucoup beaucoup moins que flash, et qu'on patch/distribue Firefox bien plus vite).
# Dans Firefox
Posté par padenot . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 10.
Alors nous, dans chez Mozilla, on aime pas bien les DRM (surprise!).
Par contre, on aime pas vraiment que le web soit non-compétitif par rapport au natif (bon, alors quand on recontextualise, cette phrase pourrait vouloir dire que le web est moins bien que le natif parce que c'est plus facile de faire du DRM avec du code natif, et là, du coup, ahem).
Du coup, on est en train d'implémenter la specification "Media Source Extensions" 1, pour que les gens puisse gérer leur buffering à la main, insérer des pubs (on peut être d'accord où pas d'accord avec ça, mais les fournisseurs de contenus en ont besoin. Perso, je préfère payer pour mon contenu, mais tout le monde n'est pas de mon avis), faire du time shifting, de l'édition vidéo, et du streaming adaptatif (on pourra faire plein d'autre chose avec, c'est que des exemples). À priori, puisqu'on aura un contrôle assez bas niveau, on pourra implémenter des DRM avec. Notez qu'en fait, ça sera assez trivial pour quelqu'un qui sait appliquer un patch et compiler un programme de récupérer le flux brut (un peu comme avec tous les systèmes de DRM, en fait, mais ça, les ayant droits n'ont pas encore bien compris).
Nous, ça nous sert principalement à faire Shumway [2], une VM flash écrite en Javascript. Quand on aura cette API, on pourra lancer (par exemple), le lecteur flash d'un site qui n'est pas passé à HTML5, sans avoir le plugin binaire (proprio ou pas) flash. Ce qui est, à mon avis complètement biaisé, une bonne chose.
Autant vous dire qu'on va essayer de se battre pour éviter au maximum d'avoir des DRM dans le web, mais qu'il y a deux-trois boites dans le secteur pas forcément de notre avis.
[2]: https://github.com/mozilla/shumway, démos: http://mozilla.github.com/shumway/
[^] # Re: Erreur sur le modèle du téléphone
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 1.
Sur mon Unagi:
Le téléphone à bien 512Mo de RAM, mais le kernel est trafiqué pour n'en utiliser 190Mo environ, afin de pouvoir être certain de pouvoir faire tourner la chose sur des configuration modestes (et donc peu onéreuses).
[^] # Re: Bétatest
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 2.
Non. Pas facilement, voir pas du tout tout court.
Il te faudrait:
- Une ROM ICS
- De grosses compétences en C et en programmation noyau pour faire/porter des drivers
- De bonnes grosses compétences en Gecko pour faire des workarounds pour les bugs desdits drivers
- Que le GPU soit assez bien
[^] # Re: Le téléphone était...
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 1.
C'est faux de dire qu'Android tourne sans ralentissement dessus. Une phrase du type "Android 2.3 tourne de manière utilisable dessus" serait déjà plus correcte. Les nombreux tests/revues que tu peux trouver sur internet sont formels, c'est pas cher, ça fait le job, mais ça tourne pas du tout sans ralentissement (OOM killer à foison, saisie de texte non fluide, pas à 60fps tout le temps, etc.).
Firefox OS non plus ne tourne pas sans ralentissement sur cet appareil, d'ailleurs.
[^] # Re: IndexedDB
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 1.
https://github.com/mozilla-b2g/gaia/blob/master/shared/js/async_storage.js. Moins flexible, mais plus facile.
[^] # Re: Accès sockets
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à -1. Dernière modification le 28 janvier 2013 à 16:16.
Parce qu'il y a beaucoup de gens (je parle des nombreux développeurs qui font du web) qui sont très heureux de pas avoir à apprendre un nouveau langage, des framework, des IDE et plein d'autres choses pour faire des applications. Aussi, tu deviens cross-platform/device facilement, tu as pas mal de sécu qui est géré pour toi. Les gens qui n'aiment pas ça pourront aller voir d'autre plateformes qui leur plairont plus, je suppose.
Perso, j'aime beaucoup le C, et j'ai aucun souci pour faire plein de trucs avec, mais la plupart des gens n'ont pas envie de se frapper des segfaults ou de la manipulation de mémoire manuelle pour faire leurs applications mobiles.
Et aussi, on est Mozilla, et on aime bien le web et on pense sincèrement que c'est une technologie viable pour les mobiles, qui nous sortirait des environnements non-compatibles de la concurrence.
[^] # Re: géniale.
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 2.
À un moment on faisait comme ça, mais plus maintenant, je sais plus pourquoi. Enfin, pour être précis, et si tu as regardé les slides, on pouvait configurer ce qu'on appelle les permissions implicites, pour autoriser une appli à faire un truc, dans les settings. Mais plus maintenant, je sais pas pourquoi (on arrive aux limites de ce que je sais sur FirefoxOS, je bosse pas dessus au jour le jour).
[^] # Re: géniale.
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 1.
Laisse nous une petite minute :-).
Une sorte de "mode développeur" est une chose vraiment importante à avoir, et on s'en est rendu compte lors de ces App Days (pas qu'on ne le savait pas, mais on pensait pas que c'était autant handicapant). On a proposé des hacks aux gens pour qu'ils puissent bosser, mais il me semble qu'une personne a quelque chose de plus générique, ça devrait arriver bientôt.
[^] # Re: géniale.
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 3.
Oui, c'est la beauté des OpenWebApp. Tu peux simplement avoir un site web, qui dispose d'un fichier "manifest.webapp", et hop, ça te fait une application. Tu peux aussi proposer un zip, ou envoyer ton app sur le store. Tu peux aussi créer ton propre store.
L'avantage d'aller sur le store Mozilla, pour l'instant, c'est que c'est le seul qui peut faire des revues de code, et donc accorder des permissions avancées aux applications.
Je pense que tu serais interessé par les slides de julienw 1, qui expliquent comment appcache fonctionne, appcache étant la technologie qui gère la persistence des assets dans les navigateurs, et qui est très utilisé dans Firefox OS.
[^] # Re: Accès sockets
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 3.
Un des buts du projet est de montrer que la plateform Web est tout à fait capable de rivaliser avec les applications natives pour la plupart des applications (bien évidemment pas toutes, on manque de temps et il faut faire des choix si on veut sortir un truc un jour).
Si tu veux écrire une application mais que tu ne peux pas, de mon point de vue, c'est qu'il faudrait qu'on expose une API pour te laisser écrire ton programme.
Sur les autres OS mobiles, de la même manière, tu n'es pas root (bien que dans certains cas, tu puisses le devenir, les utilisateurs de ton application ne le seront pas par défaut), des fois tu n'as pas accès au FS, et tu es fortement encouragé à passer par leurs API. Mais avec le temps, toutes les API nécessaires sont disponibles.
Tu peux tout à fait, par contre, tester ce que tu veux: il est relativement aisé d'écrire une API dans Gecko, flasher ton propre build, pour peu que tu te renseignes un peu avant et que tu aimes bien parler sur IRC (peu de gens refuseront de t'aider, et encore, ça serait probablement par manque de temps). Tu auras alors du levier pour convaincre les personnes d'investir leur temps dans ton API (pour faire des revues de code, nécessaire pour faire rentrer un patch, ou des revues de sécurité, etc.).
Un OS correct ne se fait pas en un jour, et c'est tout à fait avec des cas d'utilisations qu'on avait pas prévu qu'on fera quelque chose de qualité.
# Une autre imprécision
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 7.
Je pense qu'un lecteur pourrait croire qu'IonMonkey est utilisé dans Firefox OS. Il n'en est rien. En effet, IonMonkey dépend d'une autre fonctionnalité des moteurs javascript présent dans Firefox, appelée Type Inference (TI, pour inférence de types). TI est monolithique, cela voulant dire qu'on ne peut l'activer que pour une programme, pas pour, disons, une fonction d'un programme Javascript. L'empreinte mémoire est alors vraiment importante, et la mémoire disponible sur les téléphones visées (qui ont 256Mo de ram, un peu plus d'une centaine disponible pour les programmes utilisateurs) est trop faible.
L'équipe Javascript travaille aussi à augmenter les performances, avec un autre projet qui fonctionnera à priori sur Firefox OS (mais qui améliorera aussi les performances sur desktop et android), en écrivant un baseline compiler. Comme toujours, on peut suivre l'avancement de ce projet sur le bug 805241 1.
[^] # Re: Firefao, l'enfer du jeu
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 4.
Tu peux desactiver WebGL dans Gecko (via une pref). Je recommande chaudement de ne pas le faire, WebGL peut avoir bon nombre de cas d'utilisation dans des applications qui n'utilisent pas la 3d, pour accelérer le dessin. Oui, je suis d'accord, Gecko devrait le faire tout seul et c'est un hack (qu'on évite d'utiliser dans Gaia), mais en attendant qu'on optimise notre pipeline pour tous les cas d'utilisation possible et inimaginable de html css et js (autant dire que ça fait pas mal), c'est une optimisation possible.
# Erreur sur le modèle du téléphone
Posté par padenot . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 10.
Non, les téléphones que vous avez eu entre les mains n'étaient pas des Peak. En comparaison, les Peaks auront un CPU double coeur dont la fréquence sera 1.5 fois plus élevée (800MHz et un seul coeur pour le modèle de ce weekend). Le Peak disposera de 512Mo de RAM (contre 256 pour le téléphone de ce weekend), et d'un GPU vraisemblablement bien plus véloce (nécessaire puisque l'écran sera beaucoup plus grand et la résolution bien plus élevée).
Je pense qu'on peut comparer les téléphones de ce weekend (un ZTE Kis) à un téléphone Android d'il y a deux ou trois ans, en terme de matériel. La réactivité vient pour une grande partie du fait que l'équipe en charge du rendu graphique ("gfx") a su tirer parti du GPU du téléphone. Il est relativement peu puissant, mais fait toute la différence.
Les appareils Geeksphone ne seront disponibles qu'en février, et nous même les développeurs Mozilla n'y avons pas accès pour le moment.