Est-ce que GCompris a besoin de fonctionnalités présentes uniquement dans les plateformes d'applications de bureau/mobiles et non dans les standards du Web?
Si non, tu pourrais avoir uniquement une version Web consultable partout, et si tu pourrais alors l'empaqueter sous forme d'appli mobile (la moitié des applis sur Android ne sont que des pages Web locales ainsi empaquetées).
Je comprends que QML est un bon moteur de présentation, mais HTML et CSS ne sont pas mauvais non plus!
Merci pour le lien, c'est intéressant, mais ça semble confirmer mes craintes. La page 6 de ces transparents dit explicitement quel anneau ils prennent: "Polynomial ring Z_p[X]/(Xn +1)". Donc on est dans les anneaux finis. Si Xn +1 est irréductible dans Z_p[X], alors ceci n'est rien d'autre que le corps fini à pn éléments, donc chaque élément se représente sur (n log p / log 2) bits, et le groupe d'automorphismes est cyclique d'ordre n. Je suppose que la partie que je ne comprends pas tient à cette histoire de "bruit", peut-être que c'est ça qui va sauver la mise… ?
Ce que je ne comprends pas avec le chiffrement homomorphe, c'est: qu'est-ce qui fait espérer aux chercheurs qu'il existe un anneau avec suffisamment d'automorphismes pour rendre ça fonctionnel?
Bien sûr, en prenant des anneaux suffisamment gros, on peut avoir autant d'automorphismes qu'on veut, mais on retombe sur le problème mentionné dans l'article, que les opérations sur les données chiffrées sont trop lentes.
Alors on en est réduit à chercher des anneaux pas trop gros mais avec beaucoup d'automorphismes, et là je ne vois pas. Les anneaux d'entiers algébriques donnent des groupes d'automorphismes arbitraires, mais pour une dimension sur Z égale à l'ordre du groupe… ce qui n'est pas rentable. Si on va chercher en dimensions (de Zariski) supérieures, on en est réduit à espérer découvrir des variétés algébriques très symétriques, ce qui a déjà été étudié par les géomètres algébristes et je ne crois pas qu'il y en ait assez pour s'en servir de clés de cryptographi (peut-être que je me trompe?). Les anneaux finis, c'est bien sûr encore pire et bien compris; les anneaux de matrices ont certes beaucoup d'automorphismes, mais il y a alors toutes l'algèbre linéaire qui va fournir des outils à la cryptanalyse, ce qui fait que la partie semble perdue d'avance.
L'anneau qu'on voudrait vraiment ça serait quelque chose comme C, le corps des nombres complexes, qui a une foule d'automorphismes "sauvages", mais on ne sait pas représenter ces choses-là dans la mémoire finie d'un ordinateur…
Alors, quelqu'un sait-il quel genre d'anneaux les chercheurs envisagent pour établir un chiffrement complètement homomorphe viable?
Comme dit plus haut, tous les formats d'images animées sont devenus inutiles depuis que la balise <video> existe. D'autre part, APNG n'a pas à ma connaissance été adopté par d'autre fabricants de navigateurs que Mozilla et Opera, et un standard du Web qui n'est pas largement accepté, c'est toujours dommage: un coût mort pour les navigateurs et les webdevs qui l'ont soutenu. C'est pour ça qu'on fait attention avant de supporter un nouveau format!
Je pense que c'est le point essentiel découvert par l'étude: cet argument de "30%" ne repose sur rien d'autre que le choix arbitraire d'une métrique. On peut donc retourner l'argument en choisissant arbitrairement la métrique qui favorise le plus JPEG contre WebP, avec une marge similaire.
En d'autres termes, si tu veux des images 30% plus petites que test JPEGs actuels avec une qualité quasiment similaire, c'est très simple: garde JPEG et choisis un degré de compression plus élevé. WebP ne génère des images plus petites que JPEG que parce que le choix par défaut de niveau de compression est plus agressif.
Ce que je dis ici se repose bien sûr sur l'hypothèse que RGB-SSIM n'est pas plus légitime que les autres métriques utilisées dans l'étude. S'il s'avérait que RGB-SSIM était vraiment à elle seule une représentation fidèle de la qualité des images, et pas les autres métriques, alors oui WebP serait effectivement 30% plus petit à qualité égale. Mais a priori, on a quatre métriques qui donnent des résultats très différents, et RGB-SSIM n'est ni plus ni moins légitime que les trois autres.
APNG est généralement considéré comme une erreur regrettable, mais le Web est ainsi fait qu'il est difficile de retirer le support d'une technologie supportée dans la version actuelle d'un navigateur. Mais à terme, oui, ce serait une bonne chose.
mais vu que Google semble avoir aidé pas mal Mozilla au niveau financier, est-ce que cela ne serait pas un juste retour des choses de supporter ce format
Ouille! J'espère que l'avenir du Web ne dépendra jamais de ce genre de petits arrangements entre amis!
Plus généralement, Mozilla et Google sont partenaires sur certains points (par exemple le partenariat qui fait de Google le moteur de recherche par défaut dans Firefox), tout en étant en concurrence directe sur d'autre fronts, et avec des visions parfois très différentes de l'avenir du Web.
ça serait pas mal d'avoir des images montrant les différences
Les différences visibles à l'œil nu sont assez subjectives, d'où l'utilisation de métriques «mathématiques» pour départager les formats.
Est-ce que ça risque de rendre l'affichage des images plus lourd sur les ordinateurs les moins puissants ?
Très bonne question; malheureusement je ne sais absolument pas comment se comparent les différents codecs en termes de coût de décompression! Désolé. C'est une bonne question à poser par exemple sur le fil de discussion sur le Google Group mentionné dans le blog de Mozilla.
Je pense que la seule raison pour laquelle ce format n'a pas été inclus dans l'étude, est le temps: ça a déjà pris très longtemps de réaliser cette étude, car il y a un grand nombre de pièges à éviter, et la complexité augmente avec le nombre de formats testés. Maintenant que cette première étude a été publiée, je suppose que mes collègues seraient ravis de recevoir des contributions ajoutant JPEG2000 à la liste des formats étudiés, à condition que ça soit fait avec autant de soin que pour les autres formats.
JPEG2000 est aussi intéressant en ce qu'il complète le paysage actuel des formats préférés de chaque grand fabriquant de navigateurs:
- Google et Opera supportent WebP;
- Microsoft supporte JPEG -XR;
- Apple supporte JPEG2000.
C'est intéressant parce que ça souligne le fait que même si Mozilla adoptait WebP, il n'est pas du tout évident que Microsoft et Apple suivraient. Dans cette course, chacun (sauf Mozilla pour le moment) a déjà son cheval favori.
Cf ma réponse ci-dessus sur en quoi supporter plus de formats a un coût.
n'est-ce pas se tirer une balle dans le pied pour Mozilla de ne pas implémenter ce support ?
C'est en effet une position difficile, au vu de la pression existante. Il est très possible que Mozilla finisse par supporter WebP non pas pour ses qualités intrinsèques mais simplement en réaction à la pression. En attendant, on espère que l'étude qu'on vient de publier permettra au moins de contribuer des bases techniques saines au débat.
laissons aux éditeurs de contenu choisir
La question est de savoir si les avantages que ça offre justifient les coûts d'une telle décision. C'est pour aider à répondre à cette question que cette étude a été effectuée.
Question de neophyte : C'est si compliqué d'integrer un format supplementaire ?
Très bonne question. Oui, c'est assez cher de supporter un format d'images supplémentaire, pour un fabricant de navigateurs. Pour t'en convaincre, parcours les notes de version de Firefox au fil de années qui annoncent la réparation de failles de sécurité dans libpng, libjpeg, libjpeg-turbo et autres bibliothèques utilisées pour supporter les formats existants. Et au-delà des failles de sécurité, il y a tous les autres plantages et autres bugs rapportés au fil du temps sur bugzilla. Maintenant que PNG et JPEG sont des technologies assez matures, le flux de bug ralentit naturellement… jusqu'au prochain format d'images.
C'est aussi cher en termes de complexité pour le développeur Web (comment décider entre deux formats qui font presque la même chose?) et pour l'utilisateur (si je télécharge une image en WebP, comment est-ce que je la partage avec mes amis incapables de l'ouvrir?)
Alors bien sûr, tout le monde s'attend à ce qu'un jour, il y ait un format qui offre des avantages suffisants sur les formats existants pour justifier ces coûts. La question actuelle est de savoir si WebP est ce format.
Juste une chose, quand sous Android on a la Camera Preview dans une SurfaceTexture, ce n'est quand même pas exactement en temps réel un tampon DMA directement lié à la Camera, n'est-ce pas? Si c'était le cas, on lirait des images où certains pixels sont plus récents que d'autres… Je crois plutôt que la SurfaceTexture reçoit des images complètes l'une après l'autre, qui sont donc des copies de ce que la Camera a fourni à un moment donné. SurfaceTexture se comporte donc comme un EGLStream, un flux d'images. Il y a deux degrés de liberté, le nombre d'images dans le flux (par exemple 2 pour du double-buffering, et généralement une dizaine pour un flux video) et un booléen qui dit si au cas où le côté producteur aurait produit plusieurs images en avance, on doit utiliser la plus récente ou la plus ancienne. Avec ces degrés de liberté, SurfaceTexture couvre tous les besoins d'Android. J'ai hâte de voir une solution équivalente (une implémentation de EGLStream / EGLSurface utilisée partout, e.g. pour la camera) sur les bureaux libres!
Merci pour tes commentaires sur X, Wayland et Mir.
Et dans tout ça que penses-tu de la couche graphique d'Android? C'est à dire SurfaceFlinger, avec les abstractions SurfaceTexture (implémentant EGLSurface) et GraphicBuffer (représentant un unique tampon graphique)?
En tant que naïf développeur d'applications, j'aime beaucoup, parce que ce sont un très petit nombre de classes C++ avec un API agréable, une sémantique bien définie(*), la capacité de gérer tous les cas (dans Android 4, toutes les choses qui arrivent sur l'écran sont des SurfaceTexture, y compris les vidéos, la prévisualisation de la camera, les scènes rendues par OpenGL…) et cerise sur le gâteau, les concepts sous-jacents sont portables/standardisés dans EGL.
(*) oui, je sais qu'initialement la sémantique du verrouillage des tampons graphiques (GraphicBuffer) dépendait du pilote de la puce graphique. Mais ça a été résolu dans Android 4.2.
Tant que Mozilla n'arrivera pas a des perfs équivalentes (allons, prenons large, disons 90% du natif, ça fait quand même après peut-être 10% de durée de vie de la batterie en moins, déjà pas très appréciable), c'est utile pour… Avoir des perfs (ou de la batterie, au choix).
Native Client non plus n'a pas 100% des perfs "natives" hein. Et les 50% de asm.js ne sont que ce que un type seul a été capable de faire en 3 mois. On ne sait pas encore jusqu'où asm.js va pouvoir aller mais a priori on ne voit pas de raison pour qu'il plafonne en dessous de ce que peut faire un autre langage intermédiaire.
D'autre part ton commentaire suggère que tu crois que l'utilisation du CPU est proportionelle à la consommation de batterie; ça n'est pas le cas.
Argument dépassé (PNaCl), et si c'était un argument, il aurait suffit à Mozilla de faire la version portable.
Tant que PNaCl n'est pas sorti il n'y a aucune raison de croire que c'est faisable, puisque PNaCl cherche à utiliser la représentation intermédiaire de LLVM et les devs de LLVM ont averti que c'était une mauvaise idée.
Et surtout n'a pas été proposé par Mozilla.
Mozilla n'a jamais proposé un ensemble de technologies qui viendrait à remplacer tous les standards du Web par un ensemble d'APIs décidées par Mozilla seul. Ça demanderait un sacré culot. C'est ce que Google fait avec Pepper.
Le parallèle avec H264 ne marche pas. La raison de rejetter H264 initialement n'avait rien à voir avec la raison de rejetter Pepper. H264 était rejeté parce que non libre de droits et donc impossible à implémenter directement dans Firefox. Le problème avec H264 est que Firefox va devoir se reposer sur les codecs système ce qui va conduire à des cas où une même page Web peut s'afficher ou pas suivant des détails de ton système. C'est un problème de portabilité.
J'ai peut-etre compris la spec completement a l'envers, mais quand je lis les autres commentaires dans le journal j'ai l'impression que les gens mettent un peu tout et n'importe quoi dans l’appellation 'APIs DOM' (et melangent WebGL, JavaScript 'normal' et modules asm.js).
Qu'est ce que tu entends par "utilise les memes APIs"? Qu'un module asm.js peut utiliser une grande partie des APIs DOM (sans tourner en version interpretee)?
Par «APIs DOM» je veux dire les APIs exposées à JavaScript par les navigateurs. Du coup bien entendu que WebGL en fait partie, et comme asm.js est un sous-ensemble de JavaScript, cela ne fait aucune différence: le code asm.js a accès exactement aux mêmes APIs que n'importe quel code JavaScript.
Cela-dit, Mozilla prevoit d'ecrire un parseur separe pour les modules asm.js, du coup on voit plus trop l'interet d'etre un sous-ensemble de javascript.
C'est déjà fait dans Nightly et c'est un compilateur ou plutôt une nouvelle passe de compilation ajoutée à IonMonkey (initialement appelée OdinMonkey). L'intérêt d'être un sous-ensemble de JavaScript reste que le code asm.js tourne sans condition sur tous les navigateurs.
Finalement c'est plutot pour des raisons de strategie: etre pret rapidement en reutilisant l'infrastructure existante, communiquer sur le fait que ca marche partout en mode interprete (on rigole, parce que le moteur Unreal 3/4 qui tourne avec la version interpretee en haute resolution, j'attends quand meme de voir).
Je ne sais pas ce que tu veux dire par «en mode interprété». De plus en plus, dans la plupart des navigateurs, tout le code JavaScript est compilé, asm.js ou pas. D'ailleurs depuis hier il n'y a même plus d'interpréteur JS dans Gecko.
Comme je l'ai expliqué dans mon journal, même dans un navigateur dépourvu d'optimisations spécifiques asm.js, le code asm.js tend à tourner un peu plus vite que du JS normal, grâce à son typage implicite que la plupart des moteurs JS sont capables de reconnaître partiellement. Les optimisations asm.js ajoutées à Gecko ne font que formaliser ça pour le rendre systématique.
C'est pour ca que Google bosse sur PNaCl depuis un moment (oui, c'est pas si facile que ca et c'est toujours pas pret - voir au dessus pour mon avis sur la meilleure strategie).
«Pas si facile que ça» est un euphémisme. PNaCl essaye d'utiliser le langage intermédiaire de LLVM sur le Web, or les devs de LLVM ont clairement indiqué que c'était une mauvaise idée.
Ce qui gene Mozilla c'est qu'ils n'ont aucun controle dessus, pas le fait que ca soit de nouvelles APIs. Si lorsque PNaCl est stabilise Google essaye de standardiser tout ca, Mozilla serait toujours aussi contre.
Admettons un instant que PNaCl sorte en vrai. Le problème de portabilité de NaCl serait alors résolu, mais il resterait le problème que ça requiert le support des APIs Pepper, qui, comme je l'ai expliqué, est inacceptable pour tout autre développeur de navigateurs que Google, puisque ces APIs sont contrôlées par Google seul. Donc oui, Mozilla rejetterait ça même si asm.js n'existait pas, et oui ça serait parce que Mozilla n'aurait pas le contrôle nécessaire sur ces APIs, mais soyons clair, tu ne peux pas blâmer Mozilla pour ça: il est sain pour un développeur de navigateurs de rejetter une technologie qui implique de brader son influence au profit d'un concurrent, car il est sain que les APIs du Web soient contrôlées par tous les développeurs de navigateurs et non par un seul. Dans le monde réel maintenant, comme asm.js existe, Mozilla n'aurait même pas à invoquer ces raisons, puisqu'il suffirait de dire que comme PNaCl n'apporte rien qui ne puisse être fait avec asm.js et requiert bien plus de travail dédié, c'est simplement une mauvaise idée.
…Edit: oups, ce projet a été WONTFIXé, apparemment on n'y arrivera pas, Android consomme trop de mémoire… il reste vrai que Firefox OS tourne bien sur des appareils avec 256M de RAM unifiée.
Sur le bug:
I'm going to close out this bug since we no longer plan on supporting 256-meg devices. 384 megs is the minimum we plan on supporting, and is supported in FF20 and up. We can still work on some of the dependent bugs to further reduce our memory usage, which will help performance on the 384-meg devices, but this meta-bug is no longer needed.
J'ai du mal à comprendre ce que tu cherches à critiquer ici. On n'a jamais dit que le JS à la asm.js était «différent» d'un bytecode: la question n'a pas de sens, comme je vais essayer de l'expliquer maintenant. On n'a jamais non plus critiqué l'idée en soi d'utiliser un «bytecode» dans la mesure où ce «bytecode» serait vraiment utile et n'aurait pas d'inconvénient rédhibitoire. L'idée poursuivie par Mozilla ici est que tout langage peut être compilé vers tout langage, et donc en particulier que tout langage peut servir de «bytecode». À partir de là, on ne voit pas à quoi bon introduire un nouveau «bytecode» ou, pour utiliser un terme plus approprié, un nouveau «langage intermédiaire», puisque JS peut très bien remplir ce rôle. Tout langage peut être utilisé comme «bytecode», il suffit de savoir décompiler du code compilé vers ce langage. C'est clair?
Parlons maintenant de Native Client. Non content d'introduire son propre langage intermédiaire, ce qui est inutile comme je viens de l'expliquer, Native Client introduit un langage intermédiaire séparé pour chaque architecture (le code machine) ce qui casse la portabilité du Web, et Native Client introduit aussi son propre ensemble d'APIs, Pepper, remplaçant les APIs DOM, ce qui sape l'influence des autres développeurs de navigateurs. Voilà les raisons pour lesquelles Mozilla est résolument décidé à contrer Native Client. Tu peux en penser ce que tu veux, mais c'est cohérent avec les buts que Mozilla s'est fixés. J'ajoute que cet article est vraiment mon opinion personnelle: je n'en ai parlé à aucun collègue et la «comm» n'est pas mon métier.
Je ne suis sûr de rien parce que ce n'est pas mon domaine, mais je crois que c'est parce que asm.js opère sous la contrainte qu'il doit rester un sous-ensemble du JavaScript, et non un sur-ensemble: il ne peut pas rajouter de nouvelle syntaxe pour spécifier les informations de typage. Des annotations en commentaire reviendraient à une extension du langage. Donc il doit ruser en utilisant des aspects peu connus de JavaScript, tels que le fait que l'opérateur | (le OU bit-à-bit) a toujours une sémantique «entier 32 bits» et donc que (x|0) sera toujours un entier sur 32 bits quel que soit x.
La position de Mozilla sur ça c'est que c'est la beauté du Web que nos propres démos marchent mieux sur un navigateur concurrent, et qu'on doit continuer de travailler à améliorer les perfs :-) Ensuite, si tu essayes Firefox 22 (Nightly) ça devrait quand même être nettement plus rapide que la version stable actuelle.
Pour WASD, je n'ai pas de clavier Azerty ici pour tester, je pensais naivement que le jeu utiliserait des keycodes insensibles à la disposition du clavier… en tout cas, il devrait. A ce moment là il suffirait d'ajouter une API pour savoir à quel caractère correspond un keycode, si ça n'existe pas déjà.
Le jeu natif utilise un mélange de OpenGL 1 et 2. Le jeu Web n'utilise bien entendu que WebGL, ce qui est une traduction assez directe pour les appels OpenGL 2, et une traduction plus compliquée pour les appels OpenGL 1. Si, sur le pilote nouveau, les appels OpenGL 1 sont beaucoup plus rapides que leur traduction WebGL faite par Emscripten, alors oui ça pourrait expliquer une différence. Mais je ne crois pas à priori que ce soit le cas, et aussi, je crois (sans en être certain) que Sauerbraten n'utilise des appels OpenGL 1 que pour l'interface utilisateur, qui ne devrait pas représenter une part importante du rendu.
# Pourquoi pas seulement le Web?
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche GCompris change de moteur. Évalué à 1.
Est-ce que GCompris a besoin de fonctionnalités présentes uniquement dans les plateformes d'applications de bureau/mobiles et non dans les standards du Web?
Si non, tu pourrais avoir uniquement une version Web consultable partout, et si tu pourrais alors l'empaqueter sous forme d'appli mobile (la moitié des applis sur Android ne sont que des pages Web locales ainsi empaquetées).
Je comprends que QML est un bon moteur de présentation, mais HTML et CSS ne sont pas mauvais non plus!
[^] # Re: Existe-t-il des anneaux avec d'assez gros groupes d'automorphismes?
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Le chiffrement homomorphe. Évalué à 1.
Parfait, merci!
[^] # Re: Existe-t-il des anneaux avec d'assez gros groupes d'automorphismes?
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Le chiffrement homomorphe. Évalué à 1.
Hm, le système de typographie de LinuxFR a interprété
comme
ce qui n'était bien entendu pas mon intention!
[^] # Re: Existe-t-il des anneaux avec d'assez gros groupes d'automorphismes?
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Le chiffrement homomorphe. Évalué à 3. Dernière modification le 16 janvier 2014 à 14:39.
Merci pour le lien, c'est intéressant, mais ça semble confirmer mes craintes. La page 6 de ces transparents dit explicitement quel anneau ils prennent: "Polynomial ring Z_p[X]/(Xn +1)". Donc on est dans les anneaux finis. Si Xn +1 est irréductible dans Z_p[X], alors ceci n'est rien d'autre que le corps fini à pn éléments, donc chaque élément se représente sur (n log p / log 2) bits, et le groupe d'automorphismes est cyclique d'ordre n. Je suppose que la partie que je ne comprends pas tient à cette histoire de "bruit", peut-être que c'est ça qui va sauver la mise… ?
# Existe-t-il des anneaux avec d'assez gros groupes d'automorphismes?
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Le chiffrement homomorphe. Évalué à 10. Dernière modification le 14 janvier 2014 à 05:45.
Ce que je ne comprends pas avec le chiffrement homomorphe, c'est: qu'est-ce qui fait espérer aux chercheurs qu'il existe un anneau avec suffisamment d'automorphismes pour rendre ça fonctionnel?
Bien sûr, en prenant des anneaux suffisamment gros, on peut avoir autant d'automorphismes qu'on veut, mais on retombe sur le problème mentionné dans l'article, que les opérations sur les données chiffrées sont trop lentes.
Alors on en est réduit à chercher des anneaux pas trop gros mais avec beaucoup d'automorphismes, et là je ne vois pas. Les anneaux d'entiers algébriques donnent des groupes d'automorphismes arbitraires, mais pour une dimension sur Z égale à l'ordre du groupe… ce qui n'est pas rentable. Si on va chercher en dimensions (de Zariski) supérieures, on en est réduit à espérer découvrir des variétés algébriques très symétriques, ce qui a déjà été étudié par les géomètres algébristes et je ne crois pas qu'il y en ait assez pour s'en servir de clés de cryptographi (peut-être que je me trompe?). Les anneaux finis, c'est bien sûr encore pire et bien compris; les anneaux de matrices ont certes beaucoup d'automorphismes, mais il y a alors toutes l'algèbre linéaire qui va fournir des outils à la cryptanalyse, ce qui fait que la partie semble perdue d'avance.
L'anneau qu'on voudrait vraiment ça serait quelque chose comme C, le corps des nombres complexes, qui a une foule d'automorphismes "sauvages", mais on ne sait pas représenter ces choses-là dans la mémoire finie d'un ordinateur…
Alors, quelqu'un sait-il quel genre d'anneaux les chercheurs envisagent pour établir un chiffrement complètement homomorphe viable?
[^] # Re: Gonflé
Posté par Benoit Jacob (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 3.
Comme dit plus haut, tous les formats d'images animées sont devenus inutiles depuis que la balise
<video>existe. D'autre part, APNG n'a pas à ma connaissance été adopté par d'autre fabricants de navigateurs que Mozilla et Opera, et un standard du Web qui n'est pas largement accepté, c'est toujours dommage: un coût mort pour les navigateurs et les webdevs qui l'ont soutenu. C'est pour ça qu'on fait attention avant de supporter un nouveau format![^] # Re: Je retourne la question .....
Posté par Benoit Jacob (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 6.
Je pense que c'est le point essentiel découvert par l'étude: cet argument de "30%" ne repose sur rien d'autre que le choix arbitraire d'une métrique. On peut donc retourner l'argument en choisissant arbitrairement la métrique qui favorise le plus JPEG contre WebP, avec une marge similaire.
En d'autres termes, si tu veux des images 30% plus petites que test JPEGs actuels avec une qualité quasiment similaire, c'est très simple: garde JPEG et choisis un degré de compression plus élevé. WebP ne génère des images plus petites que JPEG que parce que le choix par défaut de niveau de compression est plus agressif.
Ce que je dis ici se repose bien sûr sur l'hypothèse que RGB-SSIM n'est pas plus légitime que les autres métriques utilisées dans l'étude. S'il s'avérait que RGB-SSIM était vraiment à elle seule une représentation fidèle de la qualité des images, et pas les autres métriques, alors oui WebP serait effectivement 30% plus petit à qualité égale. Mais a priori, on a quatre métriques qui donnent des résultats très différents, et RGB-SSIM n'est ni plus ni moins légitime que les trois autres.
[^] # Re: Gonflé
Posté par Benoit Jacob (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 1.
APNG est généralement considéré comme une erreur regrettable, mais le Web est ainsi fait qu'il est difficile de retirer le support d'une technologie supportée dans la version actuelle d'un navigateur. Mais à terme, oui, ce serait une bonne chose.
[^] # Re: Putain de brevets !
Posté par Benoit Jacob (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 1.
En effet :-(
Je ne connais pas la réponse à cette question, désolé.
[^] # Re: Je retourne la question .....
Posté par Benoit Jacob (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 6.
Ouille! J'espère que l'avenir du Web ne dépendra jamais de ce genre de petits arrangements entre amis!
Plus généralement, Mozilla et Google sont partenaires sur certains points (par exemple le partenariat qui fait de Google le moteur de recherche par défaut dans Firefox), tout en étant en concurrence directe sur d'autre fronts, et avec des visions parfois très différentes de l'avenir du Web.
Les différences visibles à l'œil nu sont assez subjectives, d'où l'utilisation de métriques «mathématiques» pour départager les formats.
Très bonne question; malheureusement je ne sais absolument pas comment se comparent les différents codecs en termes de coût de décompression! Désolé. C'est une bonne question à poser par exemple sur le fil de discussion sur le Google Group mentionné dans le blog de Mozilla.
[^] # Re: JPEG2000
Posté par Benoit Jacob (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 6.
Je pense que la seule raison pour laquelle ce format n'a pas été inclus dans l'étude, est le temps: ça a déjà pris très longtemps de réaliser cette étude, car il y a un grand nombre de pièges à éviter, et la complexité augmente avec le nombre de formats testés. Maintenant que cette première étude a été publiée, je suppose que mes collègues seraient ravis de recevoir des contributions ajoutant JPEG2000 à la liste des formats étudiés, à condition que ça soit fait avec autant de soin que pour les autres formats.
Cf aussi cette réponse sur le fil de discussion «officiel»: https://groups.google.com/d/msg/mozilla.dev.platform/9NKc7OeEFLM/RU3kg-C4UOsJ
JPEG2000 est aussi intéressant en ce qu'il complète le paysage actuel des formats préférés de chaque grand fabriquant de navigateurs:
- Google et Opera supportent WebP;
- Microsoft supporte JPEG -XR;
- Apple supporte JPEG2000.
C'est intéressant parce que ça souligne le fait que même si Mozilla adoptait WebP, il n'est pas du tout évident que Microsoft et Apple suivraient. Dans cette course, chacun (sauf Mozilla pour le moment) a déjà son cheval favori.
[^] # Re: Je retourne la question .....
Posté par Benoit Jacob (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 9. Dernière modification le 18 octobre 2013 à 09:12.
Cf ma réponse ci-dessus sur en quoi supporter plus de formats a un coût.
C'est en effet une position difficile, au vu de la pression existante. Il est très possible que Mozilla finisse par supporter WebP non pas pour ses qualités intrinsèques mais simplement en réaction à la pression. En attendant, on espère que l'étude qu'on vient de publier permettra au moins de contribuer des bases techniques saines au débat.
La question est de savoir si les avantages que ça offre justifient les coûts d'une telle décision. C'est pour aider à répondre à cette question que cette étude a été effectuée.
[^] # Re: et alors ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 10.
Très bonne question. Oui, c'est assez cher de supporter un format d'images supplémentaire, pour un fabricant de navigateurs. Pour t'en convaincre, parcours les notes de version de Firefox au fil de années qui annoncent la réparation de failles de sécurité dans libpng, libjpeg, libjpeg-turbo et autres bibliothèques utilisées pour supporter les formats existants. Et au-delà des failles de sécurité, il y a tous les autres plantages et autres bugs rapportés au fil du temps sur bugzilla. Maintenant que PNG et JPEG sont des technologies assez matures, le flux de bug ralentit naturellement… jusqu'au prochain format d'images.
C'est aussi cher en termes de complexité pour le développeur Web (comment décider entre deux formats qui font presque la même chose?) et pour l'utilisateur (si je télécharge une image en WebP, comment est-ce que je la partage avec mes amis incapables de l'ouvrir?)
Alors bien sûr, tout le monde s'attend à ce qu'un jour, il y ait un format qui offre des avantages suffisants sur les formats existants pour justifier ces coûts. La question actuelle est de savoir si WebP est ce format.
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 2.
Merci pour ta réponse.
Juste une chose, quand sous Android on a la Camera Preview dans une SurfaceTexture, ce n'est quand même pas exactement en temps réel un tampon DMA directement lié à la Camera, n'est-ce pas? Si c'était le cas, on lirait des images où certains pixels sont plus récents que d'autres… Je crois plutôt que la SurfaceTexture reçoit des images complètes l'une après l'autre, qui sont donc des copies de ce que la Camera a fourni à un moment donné. SurfaceTexture se comporte donc comme un EGLStream, un flux d'images. Il y a deux degrés de liberté, le nombre d'images dans le flux (par exemple 2 pour du double-buffering, et généralement une dizaine pour un flux video) et un booléen qui dit si au cas où le côté producteur aurait produit plusieurs images en avance, on doit utiliser la plus récente ou la plus ancienne. Avec ces degrés de liberté, SurfaceTexture couvre tous les besoins d'Android. J'ai hâte de voir une solution équivalente (une implémentation de EGLStream / EGLSurface utilisée partout, e.g. pour la camera) sur les bureaux libres!
# Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 7. Dernière modification le 28 août 2013 à 13:30.
Merci pour tes commentaires sur X, Wayland et Mir.
Et dans tout ça que penses-tu de la couche graphique d'Android? C'est à dire SurfaceFlinger, avec les abstractions SurfaceTexture (implémentant EGLSurface) et GraphicBuffer (représentant un unique tampon graphique)?
En tant que naïf développeur d'applications, j'aime beaucoup, parce que ce sont un très petit nombre de classes C++ avec un API agréable, une sémantique bien définie(*), la capacité de gérer tous les cas (dans Android 4, toutes les choses qui arrivent sur l'écran sont des SurfaceTexture, y compris les vidéos, la prévisualisation de la camera, les scènes rendues par OpenGL…) et cerise sur le gâteau, les concepts sous-jacents sont portables/standardisés dans EGL.
(*) oui, je sais qu'initialement la sémantique du verrouillage des tampons graphiques (GraphicBuffer) dépendait du pilote de la puce graphique. Mais ça a été résolu dans Android 4.2.
# Excellent article!
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 10.
J'ai appris beaucoup de choses, je fais circuler auprès de mes collègues de l'équipe Graphiques à Mozilla!
[^] # Re: Pas convaincu
Posté par Benoit Jacob (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 7.
Native Client non plus n'a pas 100% des perfs "natives" hein. Et les 50% de asm.js ne sont que ce que un type seul a été capable de faire en 3 mois. On ne sait pas encore jusqu'où asm.js va pouvoir aller mais a priori on ne voit pas de raison pour qu'il plafonne en dessous de ce que peut faire un autre langage intermédiaire.
D'autre part ton commentaire suggère que tu crois que l'utilisation du CPU est proportionelle à la consommation de batterie; ça n'est pas le cas.
Tant que PNaCl n'est pas sorti il n'y a aucune raison de croire que c'est faisable, puisque PNaCl cherche à utiliser la représentation intermédiaire de LLVM et les devs de LLVM ont averti que c'était une mauvaise idée.
Mozilla n'a jamais proposé un ensemble de technologies qui viendrait à remplacer tous les standards du Web par un ensemble d'APIs décidées par Mozilla seul. Ça demanderait un sacré culot. C'est ce que Google fait avec Pepper.
Le parallèle avec H264 ne marche pas. La raison de rejetter H264 initialement n'avait rien à voir avec la raison de rejetter Pepper. H264 était rejeté parce que non libre de droits et donc impossible à implémenter directement dans Firefox. Le problème avec H264 est que Firefox va devoir se reposer sur les codecs système ce qui va conduire à des cas où une même page Web peut s'afficher ou pas suivant des détails de ton système. C'est un problème de portabilité.
[^] # Re: Pas convaincu
Posté par Benoit Jacob (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 5. Dernière modification le 04 avril 2013 à 15:29.
Par «APIs DOM» je veux dire les APIs exposées à JavaScript par les navigateurs. Du coup bien entendu que WebGL en fait partie, et comme asm.js est un sous-ensemble de JavaScript, cela ne fait aucune différence: le code asm.js a accès exactement aux mêmes APIs que n'importe quel code JavaScript.
C'est déjà fait dans Nightly et c'est un compilateur ou plutôt une nouvelle passe de compilation ajoutée à IonMonkey (initialement appelée OdinMonkey). L'intérêt d'être un sous-ensemble de JavaScript reste que le code asm.js tourne sans condition sur tous les navigateurs.
Je ne sais pas ce que tu veux dire par «en mode interprété». De plus en plus, dans la plupart des navigateurs, tout le code JavaScript est compilé, asm.js ou pas. D'ailleurs depuis hier il n'y a même plus d'interpréteur JS dans Gecko.
Comme je l'ai expliqué dans mon journal, même dans un navigateur dépourvu d'optimisations spécifiques asm.js, le code asm.js tend à tourner un peu plus vite que du JS normal, grâce à son typage implicite que la plupart des moteurs JS sont capables de reconnaître partiellement. Les optimisations asm.js ajoutées à Gecko ne font que formaliser ça pour le rendre systématique.
«Pas si facile que ça» est un euphémisme. PNaCl essaye d'utiliser le langage intermédiaire de LLVM sur le Web, or les devs de LLVM ont clairement indiqué que c'était une mauvaise idée.
Admettons un instant que PNaCl sorte en vrai. Le problème de portabilité de NaCl serait alors résolu, mais il resterait le problème que ça requiert le support des APIs Pepper, qui, comme je l'ai expliqué, est inacceptable pour tout autre développeur de navigateurs que Google, puisque ces APIs sont contrôlées par Google seul. Donc oui, Mozilla rejetterait ça même si asm.js n'existait pas, et oui ça serait parce que Mozilla n'aurait pas le contrôle nécessaire sur ces APIs, mais soyons clair, tu ne peux pas blâmer Mozilla pour ça: il est sain pour un développeur de navigateurs de rejetter une technologie qui implique de brader son influence au profit d'un concurrent, car il est sain que les APIs du Web soient contrôlées par tous les développeurs de navigateurs et non par un seul. Dans le monde réel maintenant, comme asm.js existe, Mozilla n'aurait même pas à invoquer ces raisons, puisqu'il suffirait de dire que comme PNaCl n'apporte rien qui ne puisse être fait avec asm.js et requiert bien plus de travail dédié, c'est simplement une mauvaise idée.
[^] # Re: Pas convaincu
Posté par Benoit Jacob (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 3. Dernière modification le 04 avril 2013 à 15:05.
C'est vrai, Android consomme plus de mêmoire que Firefox OS, donc c'est plus difficile, mais c'est un projet qu'on essaye de mener à bien: https://bugzilla.mozilla.org/show_bug.cgi?id=792131
…Edit: oups, ce projet a été WONTFIXé, apparemment on n'y arrivera pas, Android consomme trop de mémoire… il reste vrai que Firefox OS tourne bien sur des appareils avec 256M de RAM unifiée.
Sur le bug:
[^] # Re: Pas convaincu
Posté par Benoit Jacob (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 9. Dernière modification le 04 avril 2013 à 03:34.
J'ai du mal à comprendre ce que tu cherches à critiquer ici. On n'a jamais dit que le JS à la asm.js était «différent» d'un bytecode: la question n'a pas de sens, comme je vais essayer de l'expliquer maintenant. On n'a jamais non plus critiqué l'idée en soi d'utiliser un «bytecode» dans la mesure où ce «bytecode» serait vraiment utile et n'aurait pas d'inconvénient rédhibitoire. L'idée poursuivie par Mozilla ici est que tout langage peut être compilé vers tout langage, et donc en particulier que tout langage peut servir de «bytecode». À partir de là, on ne voit pas à quoi bon introduire un nouveau «bytecode» ou, pour utiliser un terme plus approprié, un nouveau «langage intermédiaire», puisque JS peut très bien remplir ce rôle. Tout langage peut être utilisé comme «bytecode», il suffit de savoir décompiler du code compilé vers ce langage. C'est clair?
Parlons maintenant de Native Client. Non content d'introduire son propre langage intermédiaire, ce qui est inutile comme je viens de l'expliquer, Native Client introduit un langage intermédiaire séparé pour chaque architecture (le code machine) ce qui casse la portabilité du Web, et Native Client introduit aussi son propre ensemble d'APIs, Pepper, remplaçant les APIs DOM, ce qui sape l'influence des autres développeurs de navigateurs. Voilà les raisons pour lesquelles Mozilla est résolument décidé à contrer Native Client. Tu peux en penser ce que tu veux, mais c'est cohérent avec les buts que Mozilla s'est fixés. J'ajoute que cet article est vraiment mon opinion personnelle: je n'en ai parlé à aucun collègue et la «comm» n'est pas mon métier.
[^] # Re: syntaxe asm.js
Posté par Benoit Jacob (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 8. Dernière modification le 03 avril 2013 à 23:55.
Je ne suis sûr de rien parce que ce n'est pas mon domaine, mais je crois que c'est parce que asm.js opère sous la contrainte qu'il doit rester un sous-ensemble du JavaScript, et non un sur-ensemble: il ne peut pas rajouter de nouvelle syntaxe pour spécifier les informations de typage. Des annotations en commentaire reviendraient à une extension du langage. Donc il doit ruser en utilisant des aspects peu connus de JavaScript, tels que le fait que l'opérateur | (le OU bit-à-bit) a toujours une sémantique «entier 32 bits» et donc que (x|0) sera toujours un entier sur 32 bits quel que soit x.
[^] # Re: Quelques points en vrac
Posté par Benoit Jacob (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 2.
C'est déjà possible non? Touche en dessous de Echap pour afficher le menu du jeu… (je ne peux pas tester maintenant).
[^] # Re: Quelques points en vrac
Posté par Benoit Jacob (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 7.
La position de Mozilla sur ça c'est que c'est la beauté du Web que nos propres démos marchent mieux sur un navigateur concurrent, et qu'on doit continuer de travailler à améliorer les perfs :-) Ensuite, si tu essayes Firefox 22 (Nightly) ça devrait quand même être nettement plus rapide que la version stable actuelle.
Pour WASD, je n'ai pas de clavier Azerty ici pour tester, je pensais naivement que le jeu utiliserait des keycodes insensibles à la disposition du clavier… en tout cas, il devrait. A ce moment là il suffirait d'ajouter une API pour savoir à quel caractère correspond un keycode, si ça n'existe pas déjà.
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Benoit Jacob (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 3.
Le jeu natif utilise un mélange de OpenGL 1 et 2. Le jeu Web n'utilise bien entendu que WebGL, ce qui est une traduction assez directe pour les appels OpenGL 2, et une traduction plus compliquée pour les appels OpenGL 1. Si, sur le pilote nouveau, les appels OpenGL 1 sont beaucoup plus rapides que leur traduction WebGL faite par Emscripten, alors oui ça pourrait expliquer une différence. Mais je ne crois pas à priori que ce soit le cas, et aussi, je crois (sans en être certain) que Sauerbraten n'utilise des appels OpenGL 1 que pour l'interface utilisateur, qui ne devrait pas représenter une part importante du rendu.
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Benoit Jacob (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 3.
peut-être, mais là Pierre semble indiquer que le même jeu tourne nettement plus vite en natif qu'en Web sur la même machine.