Tu dis ça juste parce que tu es déçu qu'on ne puisse pas installer des appli Java certifiée J2EE, ce qui va t'empêcher de jouer au lead architect dans des beaux projets bloatw^W java pour cette plateforme.
Les plugins, ces trucs que l'on peut incorporer dans une page web au moyen d'une balise object, ce sont des "îlots" dans le navigateur. Y a une API précise et plutôt minimaliste, à respecter pour implémenter un plugin, afin que le navigateur puisse le manipuler un minimum (faire passer des valeurs via js, l'instancier, le détruire etc...). c'est la NPAPI.
La NPAPI, incorporée dans TOUT les navigateurs depuis des lustres, y compris les navigateurs libres, ne permet absolument pas de différencier un plugin libre d'un plugin proprio.
Cependant, même si ils arrivent à detecter le type de plugin (via des tests en tout genre http://www.mozilla.com/fr/plugincheck/ ), interdire des trucs qui sont en places depuis des lustres, c'est totalement contre-productif pour l'utilisateur et Mozilla n'a aucun intérêt à interdire flash (parce que là, c'est clair, du coup, les parts de marché de Firefox s'écroulent). à signaler toutefois que Mozilla combat flash d'une autre manière : en implémentant des trucs de HTML5, en améliorant le support SVG/SMILE, dans l'optique d'offrir une alternative à flash.
Par contre, ne pas supporter un NOUVEAU truc (le format H264 via la balise video) qui est pour l'instant utilisé très minoritairement, et pour laquelle il reste des chances que l'on puisse imposer un format libre (même si tu penses le contraire), ça reste à mon sens, totalement acceptable.
Enfin bref, comparer le support de flash (et encore, Mozilla ne supporte pas flash, il support les plugins implémentant la NPAPI, nuance) et le support du H264, ça n'a aucun rapport.
>The "Chrome" is Mozilla's term for the little search box to the upper right,
non, ce n'est pas vraiment exact. Dans Mozilla, depuis la nuit des temps, "chrome" désigne l'interface, et tout ce qui tourne en mode "privilegié" (les pages XUL de l'interface, les extensions...), à l'opposition à ce qui tourne en "non privilegié" (les pages web).
Pour rappel, l'interface de Firefox (menu et cie), c'est une fenêtre ayant chargé un fichier XUL+CSS+JS. Et l'adresse d'une page XUL en mode chrome (de l'application ou d'une extension), utilise un protocol custom chrome:// . Tapez par exemple chrome://browser/content/browser.xul dans la barre d'adresse (et affichez la source ;-) )
Je ne sais pas si l'appellation de "Chrome" pour le browser de Google embête Mozilla, mais personnellement, ça m'embête, car ça apporte plutôt de la confusion quand j'explique maintenant le développement XUL.
À noter que les développeurs à l'origine du navigateur Chrome, sont des anciens de Mozilla. Ceci explique peut-être cela... Si c'est eux qui ont choisi, ce n'est pas malin de leur part... m'enfin, c'est peut être tout simplement les marketeux qui ont pondu ce nom là, sans vraiment vérifier l'origine technique...
je confirme qu'ils utilisent la lib theora officielle. Ils ont même aidé, au moins financièrement, aux récents développements sur cette lib (version 1.1 de theora)
Avec un plugin flash/autre, tu n'as quasi aucun controle sur l'affichage depuis ta page web, puisque c'est une boite noire, qui a sa propre zone d'affichage qu'il est particulièrement difficile de controler (y compris par le navigateur lui même, le plugin faisant ce qu'il veut).
Avec la balise video :
- tu as une API standardisée pour manipuler la lecture de la video en javascript
- de ce fait, tu peux fournir ta propre interface utilisateur en HTML (tes propres boutons html etc, avec ton propre design et cie)
- tu peux la "manipuler" en JS, CSS ou autre, comme n'importe quel autre élément HTML.
Bref, la balise video ouvre des nouveaux possibilités d'intégration multimédia dans les navigateurs.
Et ça bien sûr, quelque soit le format sous-jacent utilisé.
>Le navigateur lui même devient lecteur vidéo. C'est ça ? Alors, si effectivement il s'agit bien de cela, je ne vois pas vraiment l'intérêt .
Si on suit ton raisonnement, il faudrait que Firefox utilise gimp ou xv pour afficher les images...
Une page web de nos jours, ce n'est plus seulement que du texte et quelques images, mais de véritables applications ou de véritables document multimédia.
>donc du oui, de la HD avec la plus haute qualite possible.
Bof. je vois pas ce que ça apporte de regarder la roue de la fortune ou le journal de 20h en HD (comme pour 90% des emissions qui passent à la télé ou le cable). À part pour les grands films, cette surenchère de qualité est juste ridicule. Juste un truc marketing de la part des fabricants de matos informatique ou electronique grand publique, pour vendre leurs produits et t'obliger à renouveller ton matos.
>Pour l'instant Theora n'a presque rien de tout ca.
parce que personne ne veut s'y mettre. c'est le serpent qui se mort la queue. Pas de puce theora parce que theora peu utilisé. Theora peu utilisé parce que pas de puce theora. Il faut donc bien essayer de pousser le format d'un coté, et briser ce cercle vicieux. C'est ce que Mozilla tente de faire, et qu'il serait bon d'encourager également.
>Mais c'est toujours plus facile de faire dire aux autres ce qu'ils n'ont pas dit. Ca fait un peu troll minable la.
Tu parlais de quel format alors ? Qui est en mesure de concurrencer H264, à part Theora ? (et à part dirac, hors course, car pire, semble-t-il, que theora en terme de BP)
>Reste que la problematique technique (utilisation d'une autre version de Theora que celle choisie par Moxilla sans patcher et tout recompiler) reste entiere. Et tu evites soigneusement de repondre a tout ca en prenant juste le seul bout ou tu peux polemiquer...
je n'évites pas. C'est juste que je n'ai rien à dire sur la problèmatique technique. Tu veux que je te dises quoi ? je n'ai jamais programmé avec gstreamer, ni avec aucune lib video. Je peux juste te dire que techniquement, d'après mes lectures, il me semble qu'utiliser gstreamer, n'est pas aussi trivial que ça en à l'air (cf les commentaires sur le bug), et comme l'a dit roc, ce n'est que déporter le problème : le gars devra installer la plupart du temps lui même le plugin. Tu crois que l'utilisateur lambda va installer ce plugin ?
bref, "out of the box", h264 ou theora, le problème reste entier. Autant alors peut être rester sur un format libre, non encombré de brevets connus. Ce que semblent expliquer Roc et Shaver.
>c'est toujours la meme chose, il mele technique et politique tout le long
oui, il donne des raisons techniques ET idéologique. Et alors ? On n'implemente pas n'importe quoi dans un logiciels juste pour la beauté de la technique. Il faut forcément une part de reflexion idéologique/politique, surtout quand on parle de licences, de brevets logiciels. Quand on choisi une licence libre ou un format ouvert, ce n'est pas juste pour des questions techniques. Il y a toujours une question politique ou idéologique derrière.
>c'est l'opinion officielle de Mozilla, vraiment?
à priori, si tu a lu le post de shaver, il semble que ça le soit quand même, puisqu'il confirme les dire de Roc. En même temps, Roc, c'est un des piliers du développement de Gecko, donc, il a beau dire que ce n'est pas l'opinion officiel, ça l'est.
À contrario, ce que j'exprime dans les commentaires, ce n'est que ma propre opinion, le résultat de ma propre compréhension du problème dont on parle. Je ne parle pas au nom de Mozilla, je ne suis qu'un tout petit contributeur bénévole au projet.
>pourquoi participer au feeback sur le bug pour le support GStreamer si c'est pour repeter en meme temps qu'il ne veut pas de tout ca
parce qu'apparement,si j'ai bien compris, ils veulent du gstreamer pour la version mobile de Firefox, pour des plateformes spécifiques (pourquoi précisement, je n'en sais rien, je ne connais pas toute l'histoire de ce bug en détails). Ils n'en veulent pas pour la version desktop.
> on ne demande pas a Mozilla (...) de pousser H264 politiquement
bah si. Fournir un support gstreamer/directshow, c'est pousser implicitement H264. ça ne va encourager personne à utiliser un format libre comme Theora.
L'avenir dira si Mozilla aura eu raison de pousser Theora. En tout cas, leurs arguments me font croire que oui. Et l'histoire leur a déjà donné raison sur d'autres sujets (activex, extensions proprio de IE etc... http://weblogs.mozillazine.org/roc/archives/2010/01/activex_(...) ). Peut être que cela sera le cas encore pour Theora.
> si c'est pour pousser une solution inferieure techniquement, j
Faut un peu arreter les conneries. Je ne vois pas à quoi ça sert de mettre de la HD partout ou du super haut niveau de qualité de h264. Theora est suffisant à 90-99% des videos que l'on trouve sur le web (en particulier la majorité des vidéos à la con que l'on trouve sur youtube et consorts).
>je parle d'ajouter un backend pour acceder aux codecs du systeme, pas de pousser H264 en particulier
c'est pourtant ce que tu sous-entend dans la deuxième partie de ton commentaire : par "Maintenant il n'y a plus qu'a attendre que Theora se retame", tu as voulu dire "vivement que H264 gagne". CQFD.
>sans attendre que Mozilla mette a jour son fork
Mozilla n'a pas de fork. Ils intégrent la libogg telle quelle (y a juste un patch pour corriger un bug, et leurs patchs sont toujours proposés en upstream)
>t'as des arguments techniques a ajouter en plus de ceux (non critiques) sur le bug pour refuser d'ajouter ce genre de chose?
Le problème n'est pas tant technique, que "philosophique" et pécunier.
Mozilla vient à nouveau de s'expliquer sur les raisons du non support de H264 :
pour des extensions comme firebug, qui utilisent beaucoup de fonctions internes non gelées, c'est risqué, et même très déconseillé. (mais on n'a pas à le faire pour firebug, l'extension est à jour)
Je parlais surtout des extensions du genre affichage d'un bouton pour la meteo.
c'est quoi cette histoire de startup notification ? Parce que chez moi, je n'ai pas de souci pour utiliser Firefox sous linux (à te croire, c'est un truc super bloquant...)
>Et j'ajouterais que cela aurait pour but de ne pas devoir revalider toutes les extensions Car un changement de version de 3.x vers 3.x+1 désactive les extensions pour non compatibilité
Ce n'est pas tout à fait exact. Le critère d'activation et désactivation est au bon vouloir du développeur. Si il met, dans son extension, qu'elle est compatible 3.*, elle ne sera pas désactivée pour toute les versions 3.x.
malheureusement, il y a pas mal d'extensions simples qui indique une compatibilité 3.5.* par ex, alors que bon, elles utilisent des apis stabilisées depuis des lustres.
il est triste ton avis sur theora, un format libre.
Poussez à l'utilisation d'un format fermé, sur un site qui prone les logiciels libres et les formats ouverts, c'est un peu être à coté de la plaque. M'enfin.
Ce qui est sûr, c'est que ce n'est pas grâce à toi que Theora va progresser.
l'interet du XML, c'est que l'encodage est en principe indiqué dans l'entete xml, et fait partie de la spec. Autrement dit, les outils qui brassent du xml savent gérer son contenu sans problème d'encodage.
Ce n'est pas le cas des fichiers de conf plain/text. À moins qu'il y ait un caractère BOM qui permet de reconnaitre de l'utf-8 (caractère qui n'est pas toujours bien supporté, surtout par les applis qui lisent les fichiers de conf), l'application, et voir même l'éditeur, ne peuvent deviner le charset utilisé (ou se trompe une fois sur deux, la divination d'un charset n'étant pas une science exacte).
Alors ok, tu peux choisir le charset dans un éditeur. Mais encore faut-il que tu saches, TOI, avec quel charset le fichier a été enregistré. Même si il y a beaucoup de chance, dans nos contrées, pour que ce soit de l'utf-8 ou de l'iso-8859-1(5).
je suis à peu prêt certain qu'il existe des plugins pour vim/emacs, qui te permettent de charger des schémas de fichiers xml ( schémas qui sont super simple à faire en relaxng par ex), et donc d'avoir, Ô magie, la complétion automatique.
IMHO, l'argument "le XML c'est trop verbeux" etc ou "trop chiant à écrire", ne tient pas. Tout éditeur de nos jours sait gérer le XML, même sans le support de schemas.
>Il est aussi possible d'écrire la conf directement dans le langage du programme
et donc, impossible pour une application tierce (comme un clicodrome pour configurer ton truc, ou un outils tiers qui exploite les possibilités de ton appli) de lire ce fichier de conf, de le modifier ou autre...
personnellement, je ne trouve pas yaml plus lisible, tout simplement parce que la syntaxe est finalement super compliquée, avec plein de signes différents, et des règles plutôt compliquées. (genre --- | vs --- > : désolé, mais à lire ça comme ça, je ne comprendre pas ce que ça veut dire, sans aller lire la spec)
Alors que XML, ok, c'est plus verbeux, mais c'est bien plus simple à écrire.
Franchement, YAML, ça ne vaut vraiment pas la pire des syntaxes wiki. C'est du grand bricolage et c'est tout sauf simple.
Quitte à utiliser un format de fichier de conf structuré sans passer par XML, autant prendre JSON. Il n'y a pas 50 signes cabalistiques à apprendre, même pour pondre des données complexes.
Pour avoir une vision la plus réaliste possible, il faut regarder les stats de sites ayant des themes que je qualifierai de "transversaux", c'est à dire des sites qui ne parlent pas de techniques, qui sont censés être consulté par n'importe qui, par l'internaute "lambda".
Et sur ce genre de site, il n'y a effectivement qu'1% d'internautes sous linux (j'ai accès à des stats de sites de ce genre). Sachant que de nos jours, tout ceux qui ont un ordinateur sont aussi internautes, on peut dire que la part de marché de linux sur le desktop est de 1% environ. malheureusement.
Mais ton impression est quand même bonne. Linux est en progression. Mais pour l'instant, cette progression de nouveaux utilisateurs est insignifiante par rapport aux dizaines de millions d'internautes. Faut pas croire que les quelques dizaines d'utilisateurs convertis par un LUG chaque mois, va faire progresser les stats mondiales de manière "significatives" ;-) (sans vouloir dénigrer le travail des LUG ou autre associations libristes). La boule de neige n'est pour le moment pas assez grosse pour que "ça se voit".
oui, ça peut preter à confusion. le powered by Mozilla, ça ne veut pas dire que c'est la fondation/société Mozilla qui "powered" le projet, mais que ce projet utilise les technologies Mozilla.
De plus, canvas avance plus vite, normal, ce n'est qu'une surface de rendu avec des primitives graphiques de base. Absolument rien à voir avec la spec de SVG qui fait plusieurs centaines de pages. (et donc plus longue et plus complexe à implémenter).
Pourquoi donc une version linux plus lente que sous windows.
1) bon déjà, faudrait tester des navigateurs de même génération. Comparer un Chromium 4 qui vient de sortir, à une "vieille" version de Firefox, c'est limite. Car en ce moment, les progrés sont énormes ET très rapide. Bref, vaut mieux comparer avec une beta 3.6 de Firefox.
2) comme ça été dit, TraceMonkey n'est pas activé en 64bit dans la version 3.5 de Firefox, mais l'est à priori dans la version 3.6. d'où de grosse différence, puisque c'est alors l'ancien moteur JS non optimisé (SpiderMonkey) qui est utilisé
3) comme je l'ai déjà dit dans un autre commentaire, il n'y a pas de "branche" spécifique à linux ou à windows. C'est le même code, le même trunk. Les deux versions partagent au moins 90% du code, parce que l'objectif de Mozilla (depuis 1998) est justement de limiter de recoder les mêmes trucs pour chaque plateforme. Ainsi donc, c'est exactement le même moteur de rendu, le même moteur JS, la même implémentation DOM, les mêmes sources pour l'interface en XUL (modulo les fichiers CSS et quelques aménagements, comme l'emplacement de l'item de menu Options et autre trucs mineurs de cet acabi) etc..
Et tout ça repose sur une même couche d'abstraction du système, que ce soit d'un point de vue graphique (lib Cairo), ou plus général (fichiers, threads, et cie : lib NSPR)
La grosse différence entre les deux, se situe donc dans l'implémentation de cette couche d'abstraction, tant dans Cairo que NSPR, mais aussi dans le toolkit utilisé (GTK sous linux, win32 sous windows et cie)
Bref, au final, les différences de perfs entre Windows et Linux, se situent principalement dans les accés au système et à l'environnement graphique. De là à dire que le sous-systeme graphique de Windows est plus performant que X... ;-)
Notons aussi que sous linux, on a les problemes de fsync (notament via sqlite). Dans la 3.6, ils ont alors essayé de limité au maximum les accés disques et les requetes SQL, pour palier à ce défaut.
Bref, la faute n'est pas entièrement celle de Mozilla, mais de aussi des libs externes utilisées.
4) la compilation. Sous windows, c'est Visual C++ qui est utilisé. Sous les autres système, GCC. Il parait que VC produit souvent du code mieux optimisé que GCC. Ceci explique peut être cela.
D'une distro à une autre, les libs externes utilisées (sqlite et cie), ne sont pas forcément la même version qu'utilisée dans les builds windows, (qui sont celles largement testées et validées par Mozilla). Peut-être alors a-ton des différences de perfs parce qu'utilisation de libs différentes (plus ancienne par ex). Pure supposition de ma part. Notons aussi que sous windows, tout est compilé en statique.
5) possible que la différence se fait sentir à cause aussi des différences entre options de compil, entre chaque distro et os. Possible aussi que les patchs ajoutés par certaines distro aient des effets de bords..
6) reste aussi le temps passé à optimiser la version Linux. Il y a des développeurs sous linux, mais comme dit Pascalc plus haut, peu de retour, peu de beta testeur, et ne représentent même pas 1% de tout les betas testeurs. Moins de retours -> moins de bug de perf "découverts". D'ailleurs, il est probable que bon nombre de ces 1% des betas testeurs utilisent les binaires vanilla de Mozilla (compilé en static, sans patchs et autre options de compil exotiques), donc peut être avec moins de différences flagrantes. ça rejoint le point 5.
Bon, et sinon, ça râle régulièrement sur ce site, à propos des perfs sous linux (souvent à juste titre, c'est vrai). Mais râler ne suffit pas. Il faut aussi des gens pour tester et pour coder. Alors n'hésitez pas à contribuer ;-)
Les versions Linux et Windows partagent au moins 90% du code, et sont dans la même branche. Les seuls grosses différences, ce sont les couches basses, donc les accès au reste de l'OS (système graphique, système de fichiers etc..)
Le moteur JS, le moteur de rendu etc, tout est absolument identique.
>il ne faut pas oublier que le bailleur de fonds de la mozfo c'est google
Google n'est pas le bailleur de fond. Il n'y a qu'un simple contrat entre la MoCo et Google : argent en echange de trafic. point barre.
Mozilla peut très bien survivre sans google. Si là, maintenant, tout de suite, le contrat était rompu, Mozilla a de quoi survivre pendant 3 ans avec les mêmes dépenses. D'ailleurs, il est possible que Mozilla puisse être auto-financé avec des réductions de dépenses.
>que mon navigateur fasse du webgl, du nacl ou du html5 : comme tu dis, on s'en b....
ouai enfin non, on s'en fout pas, enfin moi non. Parce que je veux que n'importe quel site puisse fonctionner correctement, surtout si il n'utilise que des standards (ou futur standards). Pour un utilisateur, surtout si il n'y connait que pouik en techno, un site qui ne fonctionne pas, c'est un site sur lequel il ne reviendra pas. Et si il tombe sur trop de site qui ne fonctionnent pas, il passe à un autre navigateur (si c'est un utilisateur un peu avancé).
>il vaut être pragmatique !
je pense que Mozilla est très pragmatique. Tiens, une preuve : acid3. ils sont pas à 100% parce qu'ils estiment qu'il y a des choses qui méritent plus d'attention, que le support des fontes SVG (les derniers points à gagner sur acid3 concernent ce support principalement). Et ils ont préférés par ex travailler sur le nouveau format WOFF (http://hacks.mozilla.org/2009/10/woff/ ), qui est un meilleur compromis entre les développeurs et les fondeurs.
>l'émulateur NES en JS (et je sais bien que ce n'est pas non plus un benchmark) tourne infiniment (100x) plus rapidement sous chrome que sous ffox.
La majorité des bottlenecks, que ce soit pour cet émulateur ou les gros sites avec plein de DHTML de partout, ce n'est pas la faute au moteur JS, tracemonkey, mais la faute à notre couche de communication DOM <-> JS.
ils n'ont, et n'auront jamais une extensibilité aussi forte que ce que permet Firefox. Ils sont au niveau en terme de navigation et visite des pages. Maintenant Chrome est loin d'être une plateforme de dev comme l'est Firefox. Faut bien voir ça. Firefox n'est pas qu'un moteur de rendu de page web. Chrome si (avec quelques boutons autour). Peut être que tu t'en fiches, que tu veux qu'un simple browser, mais Firefox n'en serait pas là où il est si il n'avait pas cette formidable extensibilité. Il (ou plutôt XulRunner, sur lequel est bati Firefox) a servi de base à plein d'appli.
>qu'ils seront, ET DE LOIN, les premiers à couvrir html5 (entre autres, pour remplacer gears, qui est une brique importante de l' "os chrome" pour l'offline) ...
euh, tout ce que fait gear, Firefox le fait depuis des lustres il me semble. Faut arreter un peu. En matière de support HTML5, chrome n'est pas si en avance, et Firefox ne prend en rien du retard. Et puis il n'y a pas que HTML5, mais aussi XBL2, et d'autres technos sur lesquels Chrome a encore du retard (à quand une implem XForms par ex, ou MathML).
>Ils ont aussi, à mon sens, un truc que mozilla n'a pas : faire plaisir à l'utilisateur final
ça c'est ton avis propre. Ce n'est pas l'avis des 330 millions d'utilisateurs de Firefox. Et aux dernières nouvelles, la progression de Chrome n'est pas si fantastique que ça, en terme de part de marché (surtout que Firefox continue à bien progresser aussi sur ce sujet). Il va falloir beaucoup de temps, à mon avis, avant que Chrome ne parviennent à rattraper Firefox.
le freeze, c'est dû au fait que toutes les pages web et l'interface (qui est en xul+js), s'exécutent dans le même thread (pour des raisons historiques et techniques, notamment vis à vis des extensions, mais avec le projet electrolysis, ils sont en train de changer ça). Mais ça n'empêche pas Firefox d'utiliser les threads pour tout ce qui est réseau et certains traitements en taches de fond qui ne touchent pas directement l'interface ou une page web (dans la 3.6 par ex, la recherche qui s'effectuent lorsqu'on tape dans la barre d'url se fait maintenant dans un thread).
Notons aussi que grâce aux webworkers (ff3.5), les pages web ont la possibilité de réaliser en javascript des trucs dans un thread séparé, ce qui évite les temps de "chargements" trop long.
Sinon, au niveau IPC, je ne suis pas assez calé là dedans pour t'affirmer quoi que ce soit. Je sais juste que chez Mozilla, ils ont repris la lib IPC de chromium, avec une petite API par dessus pour que ce soit simple de communiquer entre processus via javascript.
# arrete ton char(255)
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Chronique d'un flop annoncé. Évalué à 5.
[^] # Re: Petit article récapitulatif
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 5.
Les plugins, ces trucs que l'on peut incorporer dans une page web au moyen d'une balise object, ce sont des "îlots" dans le navigateur. Y a une API précise et plutôt minimaliste, à respecter pour implémenter un plugin, afin que le navigateur puisse le manipuler un minimum (faire passer des valeurs via js, l'instancier, le détruire etc...). c'est la NPAPI.
http://en.wikipedia.org/wiki/NPAPI
La NPAPI, incorporée dans TOUT les navigateurs depuis des lustres, y compris les navigateurs libres, ne permet absolument pas de différencier un plugin libre d'un plugin proprio.
Cependant, même si ils arrivent à detecter le type de plugin (via des tests en tout genre http://www.mozilla.com/fr/plugincheck/ ), interdire des trucs qui sont en places depuis des lustres, c'est totalement contre-productif pour l'utilisateur et Mozilla n'a aucun intérêt à interdire flash (parce que là, c'est clair, du coup, les parts de marché de Firefox s'écroulent). à signaler toutefois que Mozilla combat flash d'une autre manière : en implémentant des trucs de HTML5, en améliorant le support SVG/SMILE, dans l'optique d'offrir une alternative à flash.
Par contre, ne pas supporter un NOUVEAU truc (le format H264 via la balise video) qui est pour l'instant utilisé très minoritairement, et pour laquelle il reste des chances que l'on puisse imposer un format libre (même si tu penses le contraire), ça reste à mon sens, totalement acceptable.
Enfin bref, comparer le support de flash (et encore, Mozilla ne supporte pas flash, il support les plugins implémentant la NPAPI, nuance) et le support du H264, ça n'a aucun rapport.
[^] # Re: y'a tout qui s'appelle Chrome dans leur bordel
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Dans Ubuntu Lucid ce sera Yahoo qui cherchera sur le net. Évalué à 5.
non, ce n'est pas vraiment exact. Dans Mozilla, depuis la nuit des temps, "chrome" désigne l'interface, et tout ce qui tourne en mode "privilegié" (les pages XUL de l'interface, les extensions...), à l'opposition à ce qui tourne en "non privilegié" (les pages web).
Pour rappel, l'interface de Firefox (menu et cie), c'est une fenêtre ayant chargé un fichier XUL+CSS+JS. Et l'adresse d'une page XUL en mode chrome (de l'application ou d'une extension), utilise un protocol custom chrome:// . Tapez par exemple chrome://browser/content/browser.xul dans la barre d'adresse (et affichez la source ;-) )
Je ne sais pas si l'appellation de "Chrome" pour le browser de Google embête Mozilla, mais personnellement, ça m'embête, car ça apporte plutôt de la confusion quand j'explique maintenant le développement XUL.
À noter que les développeurs à l'origine du navigateur Chrome, sont des anciens de Mozilla. Ceci explique peut-être cela... Si c'est eux qui ont choisi, ce n'est pas malin de leur part... m'enfin, c'est peut être tout simplement les marketeux qui ont pondu ce nom là, sans vraiment vérifier l'origine technique...
[^] # Re: MoFo, H.264 et liberté.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 2.
[^] # Re: MoFo, H.264 et liberté.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 5.
Techniquement, (sans parler du format de la video), elle apporte beaucoup pour le developpeur web : http://ljouanneau.com/blog/post/2008/10/16/L-element-video
Avec un plugin flash/autre, tu n'as quasi aucun controle sur l'affichage depuis ta page web, puisque c'est une boite noire, qui a sa propre zone d'affichage qu'il est particulièrement difficile de controler (y compris par le navigateur lui même, le plugin faisant ce qu'il veut).
Avec la balise video :
- tu as une API standardisée pour manipuler la lecture de la video en javascript
- de ce fait, tu peux fournir ta propre interface utilisateur en HTML (tes propres boutons html etc, avec ton propre design et cie)
- tu peux la "manipuler" en JS, CSS ou autre, comme n'importe quel autre élément HTML.
Bref, la balise video ouvre des nouveaux possibilités d'intégration multimédia dans les navigateurs.
Par exemple, ça http://people.mozilla.com/~prouget/demos/mashup/video.xhtml une demo avec video + styles CSS3 appliqué dessus, tu ne peux pas le faire en utilisant un plugin (flash, vlc ou autre). Voir d'autres démos aussi http://people.mozilla.com/~prouget/demos/ avec video+svg (http://people.mozilla.com/~prouget/demos/round/index.xhtml ) etc..
Et ça bien sûr, quelque soit le format sous-jacent utilisé.
>Le navigateur lui même devient lecteur vidéo. C'est ça ? Alors, si effectivement il s'agit bien de cela, je ne vois pas vraiment l'intérêt .
Si on suit ton raisonnement, il faudrait que Firefox utilise gimp ou xv pour afficher les images...
Une page web de nos jours, ce n'est plus seulement que du texte et quelques images, mais de véritables applications ou de véritables document multimédia.
[^] # Re: Le support du HTML 5 s'améliore...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 4.
Bof. je vois pas ce que ça apporte de regarder la roue de la fortune ou le journal de 20h en HD (comme pour 90% des emissions qui passent à la télé ou le cable). À part pour les grands films, cette surenchère de qualité est juste ridicule. Juste un truc marketing de la part des fabricants de matos informatique ou electronique grand publique, pour vendre leurs produits et t'obliger à renouveller ton matos.
>Pour l'instant Theora n'a presque rien de tout ca.
parce que personne ne veut s'y mettre. c'est le serpent qui se mort la queue. Pas de puce theora parce que theora peu utilisé. Theora peu utilisé parce que pas de puce theora. Il faut donc bien essayer de pousser le format d'un coté, et briser ce cercle vicieux. C'est ce que Mozilla tente de faire, et qu'il serait bon d'encourager également.
>Mais c'est toujours plus facile de faire dire aux autres ce qu'ils n'ont pas dit. Ca fait un peu troll minable la.
Tu parlais de quel format alors ? Qui est en mesure de concurrencer H264, à part Theora ? (et à part dirac, hors course, car pire, semble-t-il, que theora en terme de BP)
>Reste que la problematique technique (utilisation d'une autre version de Theora que celle choisie par Moxilla sans patcher et tout recompiler) reste entiere. Et tu evites soigneusement de repondre a tout ca en prenant juste le seul bout ou tu peux polemiquer...
je n'évites pas. C'est juste que je n'ai rien à dire sur la problèmatique technique. Tu veux que je te dises quoi ? je n'ai jamais programmé avec gstreamer, ni avec aucune lib video. Je peux juste te dire que techniquement, d'après mes lectures, il me semble qu'utiliser gstreamer, n'est pas aussi trivial que ça en à l'air (cf les commentaires sur le bug), et comme l'a dit roc, ce n'est que déporter le problème : le gars devra installer la plupart du temps lui même le plugin. Tu crois que l'utilisateur lambda va installer ce plugin ?
bref, "out of the box", h264 ou theora, le problème reste entier. Autant alors peut être rester sur un format libre, non encombré de brevets connus. Ce que semblent expliquer Roc et Shaver.
>c'est toujours la meme chose, il mele technique et politique tout le long
oui, il donne des raisons techniques ET idéologique. Et alors ? On n'implemente pas n'importe quoi dans un logiciels juste pour la beauté de la technique. Il faut forcément une part de reflexion idéologique/politique, surtout quand on parle de licences, de brevets logiciels. Quand on choisi une licence libre ou un format ouvert, ce n'est pas juste pour des questions techniques. Il y a toujours une question politique ou idéologique derrière.
>c'est l'opinion officielle de Mozilla, vraiment?
à priori, si tu a lu le post de shaver, il semble que ça le soit quand même, puisqu'il confirme les dire de Roc. En même temps, Roc, c'est un des piliers du développement de Gecko, donc, il a beau dire que ce n'est pas l'opinion officiel, ça l'est.
À contrario, ce que j'exprime dans les commentaires, ce n'est que ma propre opinion, le résultat de ma propre compréhension du problème dont on parle. Je ne parle pas au nom de Mozilla, je ne suis qu'un tout petit contributeur bénévole au projet.
>pourquoi participer au feeback sur le bug pour le support GStreamer si c'est pour repeter en meme temps qu'il ne veut pas de tout ca
parce qu'apparement,si j'ai bien compris, ils veulent du gstreamer pour la version mobile de Firefox, pour des plateformes spécifiques (pourquoi précisement, je n'en sais rien, je ne connais pas toute l'histoire de ce bug en détails). Ils n'en veulent pas pour la version desktop.
> on ne demande pas a Mozilla (...) de pousser H264 politiquement
bah si. Fournir un support gstreamer/directshow, c'est pousser implicitement H264. ça ne va encourager personne à utiliser un format libre comme Theora.
L'avenir dira si Mozilla aura eu raison de pousser Theora. En tout cas, leurs arguments me font croire que oui. Et l'histoire leur a déjà donné raison sur d'autres sujets (activex, extensions proprio de IE etc... http://weblogs.mozillazine.org/roc/archives/2010/01/activex_(...) ). Peut être que cela sera le cas encore pour Theora.
Vive le libre et les formats ouverts.
[^] # Re: Le support du HTML 5 s'améliore...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 3.
Faut un peu arreter les conneries. Je ne vois pas à quoi ça sert de mettre de la HD partout ou du super haut niveau de qualité de h264. Theora est suffisant à 90-99% des videos que l'on trouve sur le web (en particulier la majorité des vidéos à la con que l'on trouve sur youtube et consorts).
>je parle d'ajouter un backend pour acceder aux codecs du systeme, pas de pousser H264 en particulier
c'est pourtant ce que tu sous-entend dans la deuxième partie de ton commentaire : par "Maintenant il n'y a plus qu'a attendre que Theora se retame", tu as voulu dire "vivement que H264 gagne". CQFD.
>sans attendre que Mozilla mette a jour son fork
Mozilla n'a pas de fork. Ils intégrent la libogg telle quelle (y a juste un patch pour corriger un bug, et leurs patchs sont toujours proposés en upstream)
>t'as des arguments techniques a ajouter en plus de ceux (non critiques) sur le bug pour refuser d'ajouter ce genre de chose?
Le problème n'est pas tant technique, que "philosophique" et pécunier.
Mozilla vient à nouveau de s'expliquer sur les raisons du non support de H264 :
http://weblogs.mozillazine.org/roc/archives/2010/01/video_fr(...)
http://shaver.off.net/diary/2010/01/23/html5-video-and-codec(...)
[^] # Re: A venir
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 2.
Je parlais surtout des extensions du genre affichage d'un bouton pour la meteo.
[^] # Re: Encore merci pour le support Linux
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 4.
[^] # Re: A venir
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 5.
Ce n'est pas tout à fait exact. Le critère d'activation et désactivation est au bon vouloir du développeur. Si il met, dans son extension, qu'elle est compatible 3.*, elle ne sera pas désactivée pour toute les versions 3.x.
malheureusement, il y a pas mal d'extensions simples qui indique une compatibilité 3.5.* par ex, alors que bon, elles utilisent des apis stabilisées depuis des lustres.
[^] # Re: Le support du HTML 5 s'améliore...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 8.
Poussez à l'utilisation d'un format fermé, sur un site qui prone les logiciels libres et les formats ouverts, c'est un peu être à coté de la plaque. M'enfin.
Ce qui est sûr, c'est que ce n'est pas grâce à toi que Theora va progresser.
[^] # Re: BOF
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La France et l'Allemagne déconseillent l'utilisation d'Internet Explorer. Évalué à 2.
--->[]
[^] # Re: Règle du KISS et XML
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Requête aux devs de logiciels libres. Évalué à 2.
Ce n'est pas le cas des fichiers de conf plain/text. À moins qu'il y ait un caractère BOM qui permet de reconnaitre de l'utf-8 (caractère qui n'est pas toujours bien supporté, surtout par les applis qui lisent les fichiers de conf), l'application, et voir même l'éditeur, ne peuvent deviner le charset utilisé (ou se trompe une fois sur deux, la divination d'un charset n'étant pas une science exacte).
Alors ok, tu peux choisir le charset dans un éditeur. Mais encore faut-il que tu saches, TOI, avec quel charset le fichier a été enregistré. Même si il y a beaucoup de chance, dans nos contrées, pour que ce soit de l'utf-8 ou de l'iso-8859-1(5).
[^] # Re: Règle du KISS et XML
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Requête aux devs de logiciels libres. Évalué à 1.
IMHO, l'argument "le XML c'est trop verbeux" etc ou "trop chiant à écrire", ne tient pas. Tout éditeur de nos jours sait gérer le XML, même sans le support de schemas.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Requête aux devs de logiciels libres. Évalué à 3.
et donc, impossible pour une application tierce (comme un clicodrome pour configurer ton truc, ou un outils tiers qui exploite les possibilités de ton appli) de lire ce fichier de conf, de le modifier ou autre...
Personnellement, je trouve ça ballot.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Requête aux devs de logiciels libres. Évalué à 9.
Alors que XML, ok, c'est plus verbeux, mais c'est bien plus simple à écrire.
Franchement, YAML, ça ne vaut vraiment pas la pire des syntaxes wiki. C'est du grand bricolage et c'est tout sauf simple.
Quitte à utiliser un format de fichier de conf structuré sans passer par XML, autant prendre JSON. Il n'y a pas 50 signes cabalistiques à apprendre, même pour pondre des données complexes.
[^] # Re: part de marché de Linux
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 3.5 en tête du classement des navigateurs. Évalué à 2.
Et sur ce genre de site, il n'y a effectivement qu'1% d'internautes sous linux (j'ai accès à des stats de sites de ce genre). Sachant que de nos jours, tout ceux qui ont un ordinateur sont aussi internautes, on peut dire que la part de marché de linux sur le desktop est de 1% environ. malheureusement.
Mais ton impression est quand même bonne. Linux est en progression. Mais pour l'instant, cette progression de nouveaux utilisateurs est insignifiante par rapport aux dizaines de millions d'internautes. Faut pas croire que les quelques dizaines d'utilisateurs convertis par un LUG chaque mois, va faire progresser les stats mondiales de manière "significatives" ;-) (sans vouloir dénigrer le travail des LUG ou autre associations libristes). La boule de neige n'est pour le moment pas assez grosse pour que "ça se voit".
[^] # Re: Excellent logiciel ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal SongBird. Évalué à 2.
http://www.mozilla.org/projects/powered-by.html
[^] # Re: Rectification
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal SongBird. Évalué à 5.
http://www.mozilla.org/projects/mozilla-based.html
https://developer.mozilla.org/en/XULRunner_Hall_of_Fame
;-)
(ok, y a pas autant que d'applis en gtk ou qt, mais quand même :-) )
[^] # Re: Encore combien de temps ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Point sur le format SVG. Évalué à 1.
Faut pas confondre document et API. http://ljouanneau.com/blog/post/2009/03/26/Differences-entre(...)
De plus, canvas avance plus vite, normal, ce n'est qu'une surface de rendu avec des primitives graphiques de base. Absolument rien à voir avec la spec de SVG qui fait plusieurs centaines de pages. (et donc plus longue et plus complexe à implémenter).
# des reponses
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance des navigateur web: linux parent pauvre ?. Évalué à 10.
1) bon déjà, faudrait tester des navigateurs de même génération. Comparer un Chromium 4 qui vient de sortir, à une "vieille" version de Firefox, c'est limite. Car en ce moment, les progrés sont énormes ET très rapide. Bref, vaut mieux comparer avec une beta 3.6 de Firefox.
2) comme ça été dit, TraceMonkey n'est pas activé en 64bit dans la version 3.5 de Firefox, mais l'est à priori dans la version 3.6. d'où de grosse différence, puisque c'est alors l'ancien moteur JS non optimisé (SpiderMonkey) qui est utilisé
3) comme je l'ai déjà dit dans un autre commentaire, il n'y a pas de "branche" spécifique à linux ou à windows. C'est le même code, le même trunk. Les deux versions partagent au moins 90% du code, parce que l'objectif de Mozilla (depuis 1998) est justement de limiter de recoder les mêmes trucs pour chaque plateforme. Ainsi donc, c'est exactement le même moteur de rendu, le même moteur JS, la même implémentation DOM, les mêmes sources pour l'interface en XUL (modulo les fichiers CSS et quelques aménagements, comme l'emplacement de l'item de menu Options et autre trucs mineurs de cet acabi) etc..
Et tout ça repose sur une même couche d'abstraction du système, que ce soit d'un point de vue graphique (lib Cairo), ou plus général (fichiers, threads, et cie : lib NSPR)
La grosse différence entre les deux, se situe donc dans l'implémentation de cette couche d'abstraction, tant dans Cairo que NSPR, mais aussi dans le toolkit utilisé (GTK sous linux, win32 sous windows et cie)
Bref, au final, les différences de perfs entre Windows et Linux, se situent principalement dans les accés au système et à l'environnement graphique. De là à dire que le sous-systeme graphique de Windows est plus performant que X... ;-)
Notons aussi que sous linux, on a les problemes de fsync (notament via sqlite). Dans la 3.6, ils ont alors essayé de limité au maximum les accés disques et les requetes SQL, pour palier à ce défaut.
Bref, la faute n'est pas entièrement celle de Mozilla, mais de aussi des libs externes utilisées.
4) la compilation. Sous windows, c'est Visual C++ qui est utilisé. Sous les autres système, GCC. Il parait que VC produit souvent du code mieux optimisé que GCC. Ceci explique peut être cela.
D'une distro à une autre, les libs externes utilisées (sqlite et cie), ne sont pas forcément la même version qu'utilisée dans les builds windows, (qui sont celles largement testées et validées par Mozilla). Peut-être alors a-ton des différences de perfs parce qu'utilisation de libs différentes (plus ancienne par ex). Pure supposition de ma part. Notons aussi que sous windows, tout est compilé en statique.
5) possible que la différence se fait sentir à cause aussi des différences entre options de compil, entre chaque distro et os. Possible aussi que les patchs ajoutés par certaines distro aient des effets de bords..
6) reste aussi le temps passé à optimiser la version Linux. Il y a des développeurs sous linux, mais comme dit Pascalc plus haut, peu de retour, peu de beta testeur, et ne représentent même pas 1% de tout les betas testeurs. Moins de retours -> moins de bug de perf "découverts". D'ailleurs, il est probable que bon nombre de ces 1% des betas testeurs utilisent les binaires vanilla de Mozilla (compilé en static, sans patchs et autre options de compil exotiques), donc peut être avec moins de différences flagrantes. ça rejoint le point 5.
Bon, et sinon, ça râle régulièrement sur ce site, à propos des perfs sous linux (souvent à juste titre, c'est vrai). Mais râler ne suffit pas. Il faut aussi des gens pour tester et pour coder. Alors n'hésitez pas à contribuer ;-)
[^] # Re: Linux parent pauvre du fait de part de marché
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance des navigateur web: linux parent pauvre ?. Évalué à 4.
Les versions Linux et Windows partagent au moins 90% du code, et sont dans la même branche. Les seuls grosses différences, ce sont les couches basses, donc les accès au reste de l'OS (système graphique, système de fichiers etc..)
Le moteur JS, le moteur de rendu etc, tout est absolument identique.
[^] # Re: Linux parent pauvre du fait de part de marché
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance des navigateur web: linux parent pauvre ?. Évalué à 4.
Google n'est pas le bailleur de fond. Il n'y a qu'un simple contrat entre la MoCo et Google : argent en echange de trafic. point barre.
Mozilla peut très bien survivre sans google. Si là, maintenant, tout de suite, le contrat était rompu, Mozilla a de quoi survivre pendant 3 ans avec les mêmes dépenses. D'ailleurs, il est possible que Mozilla puisse être auto-financé avec des réductions de dépenses.
[^] # Re: bravo ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 6.
ouai enfin non, on s'en fout pas, enfin moi non. Parce que je veux que n'importe quel site puisse fonctionner correctement, surtout si il n'utilise que des standards (ou futur standards). Pour un utilisateur, surtout si il n'y connait que pouik en techno, un site qui ne fonctionne pas, c'est un site sur lequel il ne reviendra pas. Et si il tombe sur trop de site qui ne fonctionnent pas, il passe à un autre navigateur (si c'est un utilisateur un peu avancé).
>il vaut être pragmatique !
je pense que Mozilla est très pragmatique. Tiens, une preuve : acid3. ils sont pas à 100% parce qu'ils estiment qu'il y a des choses qui méritent plus d'attention, que le support des fontes SVG (les derniers points à gagner sur acid3 concernent ce support principalement). Et ils ont préférés par ex travailler sur le nouveau format WOFF (http://hacks.mozilla.org/2009/10/woff/ ), qui est un meilleur compromis entre les développeurs et les fondeurs.
>l'émulateur NES en JS (et je sais bien que ce n'est pas non plus un benchmark) tourne infiniment (100x) plus rapidement sous chrome que sous ffox.
La majorité des bottlenecks, que ce soit pour cet émulateur ou les gros sites avec plein de DHTML de partout, ce n'est pas la faute au moteur JS, tracemonkey, mais la faute à notre couche de communication DOM <-> JS.
Dans l'exécution d'une page web, il y a pleins de trucs qui entre en action, comme c'est expliqué sur http://blogs.msdn.com/ie/archive/2009/11/18/an-early-look-at(...) , faut donc pas mettre toutes les fautes sur le moteur JS.
>Ils sont arrivés "au niveau" de firefox en un an
ils n'ont, et n'auront jamais une extensibilité aussi forte que ce que permet Firefox. Ils sont au niveau en terme de navigation et visite des pages. Maintenant Chrome est loin d'être une plateforme de dev comme l'est Firefox. Faut bien voir ça. Firefox n'est pas qu'un moteur de rendu de page web. Chrome si (avec quelques boutons autour). Peut être que tu t'en fiches, que tu veux qu'un simple browser, mais Firefox n'en serait pas là où il est si il n'avait pas cette formidable extensibilité. Il (ou plutôt XulRunner, sur lequel est bati Firefox) a servi de base à plein d'appli.
>qu'ils seront, ET DE LOIN, les premiers à couvrir html5 (entre autres, pour remplacer gears, qui est une brique importante de l' "os chrome" pour l'offline) ...
euh, tout ce que fait gear, Firefox le fait depuis des lustres il me semble. Faut arreter un peu. En matière de support HTML5, chrome n'est pas si en avance, et Firefox ne prend en rien du retard. Et puis il n'y a pas que HTML5, mais aussi XBL2, et d'autres technos sur lesquels Chrome a encore du retard (à quand une implem XForms par ex, ou MathML).
>Ils ont aussi, à mon sens, un truc que mozilla n'a pas : faire plaisir à l'utilisateur final
ça c'est ton avis propre. Ce n'est pas l'avis des 330 millions d'utilisateurs de Firefox. Et aux dernières nouvelles, la progression de Chrome n'est pas si fantastique que ça, en terme de part de marché (surtout que Firefox continue à bien progresser aussi sur ce sujet). Il va falloir beaucoup de temps, à mon avis, avant que Chrome ne parviennent à rattraper Firefox.
Enfin bon, on verra...
[^] # Re: Questions...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 2.
Notons aussi que grâce aux webworkers (ff3.5), les pages web ont la possibilité de réaliser en javascript des trucs dans un thread séparé, ce qui évite les temps de "chargements" trop long.
Sinon, au niveau IPC, je ne suis pas assez calé là dedans pour t'affirmer quoi que ce soit. Je sais juste que chez Mozilla, ils ont repris la lib IPC de chromium, avec une petite API par dessus pour que ce soit simple de communiquer entre processus via javascript.