Où l'on voit les effets secondaires indésirables de surévaluer l'importance du bête toolkit au point d'en faire le facteur principal qui va déterminer quand lancer une nouvelle version majeure. Cf mon autre commentaire ci-dessous.
Il y a quelques années j'étais convaincu de l'importance d'avoir un bon toolkit. D'où mon intérêt pour Qt et KDE. Plus maintenant.
Un toolkit, en fait c'est juste quelque chose qui doit faire tourner une boucle d'événements et afficher de bêtes boutons. Ça n'est pas très intéressant et ça ne mérite pas qu'on se tape le cul par terre comme une libellule au printemps.
Qt s'est embarqué dans une bien plus vaste entreprise, celle d'offrir un cadre de développement d'applications C++ complet, remplaçant bien des composants allant de la bibliothèque standard (QVector, QList) à la gestion de bases de données SQL (QtSQL) en passant par la créations de contextes OpenGL (QtOpenGL) mais je ne suis absolument pas convaincu que cette intégration extrême de tous les besoins d'une application dans un projet unique soit bénéfique aux applications, surtout que j'ai découvert à Mozilla que les applications vraiment avancées auront toujours besoin de plus de contrôle manuel que ce qu'une panoplie à la Qt peut offrir.
Quant à Plasma Active: ce projet a-t-il vraiment des exemples de matériels à succès démontrant son utilité? Désolé, je suis devenu un peu cynique. C'est peut-être aussi l'expérience de travailler sur des plateformes mobiles, mais toujours est-il que je ne pense pas que l'on puisse offrir une bonne expérience mobile en restant au haut niveau auquel travaille Qt. Offrir une bonne expérience mobile, ca nécessite toutes sortes de hacks de bas niveau pour tirer le meilleur parti de ces matériels très limités (un peu comme de programmer un Amstrad CPC dans les années 80), et ces hacks sont hors de portée d'un projet comme KDE qui a pour credo qu'on peut se reposer aveuglément sur Qt, ou même de Qt qui a pour credo qu'on peut se reposer aveuglément sur l'OS sous-jacent. Tant que le mobile restera la jungle que c'est aujourd'hui, il n'y aura pas de place pour ces tentatives se reposant naïvement sur la qualité et la bonne performance des couches sous-jacentes.
En effet, pour faire des apostrophes j´ai fait touche apostrophe + touche apostrophe, mais il semble que j'aurais dû faire touche apostrophe + barre d'espace.
Oh oui, que Nokia est un bon exemple de réécritures inutiles, que je regrette de ne pas avoir mentionné.
Mais je ne fais pas la même interprétation de la décision d'Elop. Pour moi, Elop n'a fait qu'ajouter une entrée de plus dans la longue liste des réécritures inutiles:
- Elop décide que Windows Mobile c'est mieux que Qt.
Bref, un exemple de plus.
+1 pour les transitions itératives, c'est bien le contraire des réécritures que je pourfends. Je n'en sais pas assez sur QML pour savoir si ça tombe dans cette catégorie.
Roh, je ne connaissais pas le "QWERTY international". Ca a bien l'air d'etre ce dont j'ai besoin. Et je tourne encore sous KDE (auquel je contribuais un peu il y a quelques annees).
"baser" est utilise dans ton exemple dans un sens nettement different de son sens courant aujourd'hui: dans ton exemple, classe "ART MILIT", il veut dire etre rattache a une base militaire, c'est certes precis, mais ca n'est pas la facon dont il est employe couramment aujourd'hui.
Cool comme adjectif ça veut dire frais. Où est le problème, c'est cool.
Le probleme est que ca n'est presque jamais employe dans le sens de "frais" (qui a la qualite de fraicheur). C'est employe en remplacement de "a la mode", "sympathique", "calme", etc. Donc a la place d'utiliser des expressions francaises precises, on va utiliser ce mot anglais qui a une dizaine de sens differents. C'est plus facile puisqu'on a moins a reflechir a ce que l'on veut vraiment dire, mais on perd en nuance.
On dirait avoir du sens effectivement, on utilise aussi prendre du sens. Faire sens est quand même pas trop moche.
On peut certes dire "avoir du sens" ou "prendre du sens" et c'est deja mieux que d'utiliser le verbe "faire" a contre-emploi. Cependant, mon reproche contre "faire du sens" va au-dela de ca: aucune de ces variantes n'est precise. Le probleme est que la tournure "(verbe) du sens" est foncierement un anglicisme, alors qu'en francais on dispose de constructions bien plus precises a utiliser a la place, qui vont chacune avoir une nuance differente:
- etre sense
- etre coherent
- se defendre
- se tenir
…
Avec des accents c'est tout à fait français : être basé sur dans le sens avoir comme base.
C'est triste que la presence d'accents suffise a te faire accepter une expression aussi pauvre. La encore c'est une construction directement empruntee a l'anglais qui va rentrer en competition avec des formes francaises preexistantes et plus precises/nuancees:
- avoir pour fondement
- avoir pour point de depart
- se reposer sur
- etre fonde sur
- etre construit sur
Commandement ? Direction ?
La tu as repondu toi-meme a la question en identifiant deux sens possibles de "leadership", montrant par-la que ce terme est flou et gagne a etre remplace par des termes francais plus precis. Il y en a encore d'autres: charisme, excellence, emulation… autant de nuances qu'on perd quand on remplace tous ces mots par l'unique "leadership".
Je ne suis pas contre tous les anglicismes, c'est pour ca que je parlais de mauvais anglicismes, facon de reconnaitre qu'il en existe d'autres qui sont bons.
Un bon anglicisme enrichit la langue; un mauvais anglicisme l'appauvrit en compromettant ses qualites.
Une qualite importante de la langue francaise est sa precision, alors que l'anglais est souvent plus flou. Par la, un schema typique de mauvais anglicisme est l'importation du flou anglais dans la langue francaise. Galerie des horreurs:
- cool comme adjectif (je n'ai rien contre cool comme interjection)
- ca fait sens
- etre base sur
- leadership
Ces anglicismes sont mauvais parce qu'ils sont moins nuances que les expressions francaises preexistantes.
Je ne comprends pas ton commentaire: apparemment tu connais bien mieux la langue que moi tu tu as vu une erreur que je ne vois pas dans ce que j'ai ecrit. Pourrais-tu dire plus specifiquement ou est l'erreur?
Je ne comprends pas non plus ta pique sur le 'deprecated'. Fais-tu reference a un anglicisme que j'aurais commis? Lequel?
Bon, les petits gars. On va passer sur le fait que vos commentaires de fins lettres qu'offense l'absence d'accents ne sont eux-memes pas exempts d'erreurs de syntaxe et de typographie. Et que vous n'avez pas releve quelque chose qui aurait du plaire aux fervents defenseurs de la langue: l'absence de mauvais anglicismes.
A la rigueur, "OSS117 : l'API est bonne", ca pourrait faire un bon mot de passe. A part ca, on est bien d'accord qu'on parle de l'API "tout est un fichier et pour lire un son il suffit de l'envoyer sur /dev/audio" ? "Tout est un fichier" est l'un des principes inalienables d'UNIX decides un jour par un barbu dans les annees 70. Comme disait OSS justement, "vous vous en lasserez… va falloir se decider a grandir!"
Pour info, ce que tu demandes sur le regroupement des fenetres dans la fenetre principale est deja en cours de developpement! Dans Nightly, les telechargements sont deja integres dans la fenetre principale, et il y a une option (dans about:config) pour que les Preferences soient une page about: comme tu le suggeres, ca s'appelle les "in-content preferences". http://msujaws.wordpress.com/2012/05/10/in-content-preferences-are-now-available-in-firefox-nightly/
Bon alors on oublie texture-from-pixmap: meme quand c'est disponible, ca marche trop mal pour les cas d'utilisation d'un navigateur web moderne. Notre projet actuellement est d'arreter completement d'utiliser des pixmaps X et a la place de n'utiliser que 1) OpenGL et 2) du rendu purement logiciel (comme Chrome, d'ailleurs). Tu peux en fait deja experimenter ca dans Nightly en allant dans about:config et en mettant layers.acceleration.force-enabled=true et gfx.xrender.enabled=false, et ca te donnera de tres bonnes perfs WebGL mais on a encore quelques problemes de performance dans d'autres cas a regler avant de pouvoir activer ca par defaut.
Dommage que notre service de presse n'ait qu'une tres vague idee de ce que nous faisons, voici par exemple un compte-rendu des ameliorations dans la couche graphique dans Gecko 13:
Il y a en effet bien des notions differentes d'"ouvert" et on a ici un cas typique chez Google: le code source est ouvert, mais pas la conception/gouvernance/direction. De notre point de vue a nous, ca n'a aucun interet que Native Client soit open source puisque l'idee meme nous semble mauvaise, nous semble saper les bases du Web portable et bidouillable, et nous semble non-necessaire au vu des avancees du HTML et du JavaScript ces jours-ci.
Une application Native Client, c'est du code machine (x86 ou ARM). Ce n'est pas quelque-chose que l'on peut en general, de facon raisonnable, recompiler pour une autre architecture. Il y avait un projet, "Portable Native Client", qui devait offrir une representation intermediaire (IR) portable pour supporter n'importe quelle machine client, mais ce projet a du plomb dans l'aile: ils voulaient utiliser l'IR du compilateur LLVM, ce qui est une mauvaise idee d'apres les developpeurs de LLVM.
D'autre part, JavaScript est, de nos jours un langage compile tout court. Ensuite on peut souhaiter qu'apparaisse une meilleure alternative comme representation intermediaire, mais en attendant, ca marche bien mieux que ce que croient beaucoup de gens: essaye ce lien dans Firefox 15 (Nightly) ou Chrome Dev/Canary, et clique sur "full screen". C'est un jeu C++ OpenGL trans-compile en JavaScript et WebGL, et ca marche a 50 FPS chez moi! (Dans Firefox Nightly sous Linux je conseillerais les options layers.acceleration.force-enabled=true et gfx.xrender.enabled=false pour avoir de bonnes perfs).
(Avertissement: je travaille a Mozilla) C'est sur que Google fait beaucoup de choses tres bien pour le Web ouvert, bien plus qu'Apple et a plus forte raison encore que Facebook. Par exemple, sur WebGL, l'equipe de Google fait un travail formidable. Mais Google est malin: ils font a la fois de l'ouvert et du ferme, comme ca, ils gagnent dans tous les cas. Par exemple, pour le futur des jeux video en ligne, Google pousse certes les standards du Web (HTML5, WebGL etc) mais ils poussent encore beaucoup beaucoup plus leur propre solution "Native Client" qui est en gros le retour du bon vieux plugin binaire avec certes une meilleure securite. Ils presentent ca comme un truc ouvert auquel tous les fabriquants de navigateurs sont invites a participer, mais bien evidemment que nous on n'a pas envie d'encourager le retour des plugins binaires, et bien evidemment les APIs de Native Client ont deja ete decidees et pas de la facon dont elles auraient ete decidees si on avait participe (portabilite insuffisante, par exemple).
Cette page n'utilise bien entendu pas WebGL, c'est une demo technologique pour IE9! Url en microsoft.com.
C'est bizarre qu'elle n'affiche rien chez toi, ca laisse supposer un gros bug de XRender.
Pour repondre a ton autre question, WebGL fonctionne sous linux depuis le debut (il y avait certes peu de pilotes autorises dans Firefox 4 et 5, probleme resolu depuis).
Par exemple, cette page tourne beaucoup plus vite dans Firefox quand ton pilote XRender accelere bien les operations dont elle a besoin (marche bien sur NVIDIA proprio et ATI libre 'radeon' au moins):
J'avais bien compris, mais ce que je ne comprends pas c'est pourquoi il y a une différence, pour moi les deux ce sont des buffers dans un GPU.
On est bien d'accord! C'est pourquoi la situation est totalement absurde. Le concept est le meme, on a juste 2 implementation differents (pixmaps contre textures) et des frottements entre les 2.
Le seul truc qui ait jamais ete retire d'OpenGL c'est le vieux pipeline a fonctionnalite fixe. Au contraire, les fonctions utiles a la 2D sont un domaine ou du travail est fait cf par exemple l'extension NV_path_rendering.
Tous les systemes graphiques sont asynchrones, mais seul X11 pretend abstraire completement la presence d'un reseau entre le client et le serveur.
Pour (1) imagine par exemple qu'on a rendu un paragraphe de texte avec Cairo dans un pixmap. Pour le compositing OpenGL, on va avoir besoin de lire ce pixmap depuis OpenGL, ce qui necessite de l'interpreter comme une texture.
Pour (2), note que OpenGL, comme X11, est une architecture client-serveur, concue elle aussi pour bien marcher en reseau. Il est vrai que pour du rendu 2D en reseau, XRender permet d'aller plus loin qu'OpenGL, parce que dans le rendu 2D, tout ne peut pas toujours etre fait par OpenGL. Mais la bonne facon de resoudre ca est de continuer d'etendre OpenGL pour couvrir ces besoins (la 2D, c'est dur).
Pour (3), je n'ai pas dit que c'etait facile. Tu peux voir mon point 3 comme un argument soulignant le cout reel d'avoir une architecture asynchrone en reseau. Il ne faut pas se voiler la face, X a ete concu pour des reseaux et quand on fait tourner un serveur X dans son petit portable en local, on paye bel et bien un cout pour ca, aussi bien en termes de perfs pour l'utilisateur, qu'en termes de complexite/bugs pour le developpeur d'applications.
Pour (4), en effet c'est probablement un probleme des pilotes.
Je ne sais pas si d'autres personnes a Mozilla ont fait part de nos besoins aux devs de Wayland, mais c'est en effet quelque chose a garder en tete.
A priori, comme tous les autres systemes a part X11 (Windows, Mac, Android) font le boulot correctement, on n'est pas inquiets: les problemes de X11 semblent specifiques a X11. Sauf mon point 4 peut-etre, mais si c'est un probleme au niveau des pilotes, c'est orthogonal a X-contre-Wayland.
[^] # Re: KDE4
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 6.
Où l'on voit les effets secondaires indésirables de surévaluer l'importance du bête toolkit au point d'en faire le facteur principal qui va déterminer quand lancer une nouvelle version majeure. Cf mon autre commentaire ci-dessous.
[^] # Re: Motif
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 10. Dernière modification le 13 août 2012 à 07:12.
Il y a quelques années j'étais convaincu de l'importance d'avoir un bon toolkit. D'où mon intérêt pour Qt et KDE. Plus maintenant.
Un toolkit, en fait c'est juste quelque chose qui doit faire tourner une boucle d'événements et afficher de bêtes boutons. Ça n'est pas très intéressant et ça ne mérite pas qu'on se tape le cul par terre comme une libellule au printemps.
Qt s'est embarqué dans une bien plus vaste entreprise, celle d'offrir un cadre de développement d'applications C++ complet, remplaçant bien des composants allant de la bibliothèque standard (QVector, QList) à la gestion de bases de données SQL (QtSQL) en passant par la créations de contextes OpenGL (QtOpenGL) mais je ne suis absolument pas convaincu que cette intégration extrême de tous les besoins d'une application dans un projet unique soit bénéfique aux applications, surtout que j'ai découvert à Mozilla que les applications vraiment avancées auront toujours besoin de plus de contrôle manuel que ce qu'une panoplie à la Qt peut offrir.
Quant à Plasma Active: ce projet a-t-il vraiment des exemples de matériels à succès démontrant son utilité? Désolé, je suis devenu un peu cynique. C'est peut-être aussi l'expérience de travailler sur des plateformes mobiles, mais toujours est-il que je ne pense pas que l'on puisse offrir une bonne expérience mobile en restant au haut niveau auquel travaille Qt. Offrir une bonne expérience mobile, ca nécessite toutes sortes de hacks de bas niveau pour tirer le meilleur parti de ces matériels très limités (un peu comme de programmer un Amstrad CPC dans les années 80), et ces hacks sont hors de portée d'un projet comme KDE qui a pour credo qu'on peut se reposer aveuglément sur Qt, ou même de Qt qui a pour credo qu'on peut se reposer aveuglément sur l'OS sous-jacent. Tant que le mobile restera la jungle que c'est aujourd'hui, il n'y aura pas de place pour ces tentatives se reposant naïvement sur la qualité et la bonne performance des couches sous-jacentes.
[^] # Re: Effet de bord des accents ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 1.
En effet, pour faire des apostrophes j´ai fait touche apostrophe + touche apostrophe, mais il semble que j'aurais dû faire touche apostrophe + barre d'espace.
[^] # Re: Nokia et Maemo/Meego est aussi un bon exemple
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 8.
Oh oui, que Nokia est un bon exemple de réécritures inutiles, que je regrette de ne pas avoir mentionné.
Mais je ne fais pas la même interprétation de la décision d'Elop. Pour moi, Elop n'a fait qu'ajouter une entrée de plus dans la longue liste des réécritures inutiles:
- Elop décide que Windows Mobile c'est mieux que Qt.
Bref, un exemple de plus.
+1 pour les transitions itératives, c'est bien le contraire des réécritures que je pourfends. Je n'en sais pas assez sur QML pour savoir si ça tombe dans cette catégorie.
[^] # Re: Sous KDE, pas de souci
Posté par Benoit Jacob (site web personnel) . En réponse au journal Comment taper les accents sur un clavier QWERTY?. Évalué à 5.
voilà, problème réglé! merci!
[^] # Re: Sous KDE, pas de souci
Posté par Benoit Jacob (site web personnel) . En réponse au journal Comment taper les accents sur un clavier QWERTY?. Évalué à 2.
Roh, je ne connaissais pas le "QWERTY international". Ca a bien l'air d'etre ce dont j'ai besoin. Et je tourne encore sous KDE (auquel je contribuais un peu il y a quelques annees).
[^] # Re: Ah les francais...
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 1ere partie: eviter de sous-estimer la competition sur le plan technique. Évalué à 1.
"baser" est utilise dans ton exemple dans un sens nettement different de son sens courant aujourd'hui: dans ton exemple, classe "ART MILIT", il veut dire etre rattache a une base militaire, c'est certes precis, mais ca n'est pas la facon dont il est employe couramment aujourd'hui.
[^] # Re: Ah les francais...
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 1ere partie: eviter de sous-estimer la competition sur le plan technique. Évalué à -1. Dernière modification le 12 août 2012 à 15:08.
Le probleme est que ca n'est presque jamais employe dans le sens de "frais" (qui a la qualite de fraicheur). C'est employe en remplacement de "a la mode", "sympathique", "calme", etc. Donc a la place d'utiliser des expressions francaises precises, on va utiliser ce mot anglais qui a une dizaine de sens differents. C'est plus facile puisqu'on a moins a reflechir a ce que l'on veut vraiment dire, mais on perd en nuance.
On peut certes dire "avoir du sens" ou "prendre du sens" et c'est deja mieux que d'utiliser le verbe "faire" a contre-emploi. Cependant, mon reproche contre "faire du sens" va au-dela de ca: aucune de ces variantes n'est precise. Le probleme est que la tournure "(verbe) du sens" est foncierement un anglicisme, alors qu'en francais on dispose de constructions bien plus precises a utiliser a la place, qui vont chacune avoir une nuance differente:
- etre sense
- etre coherent
- se defendre
- se tenir
…
C'est triste que la presence d'accents suffise a te faire accepter une expression aussi pauvre. La encore c'est une construction directement empruntee a l'anglais qui va rentrer en competition avec des formes francaises preexistantes et plus precises/nuancees:
- avoir pour fondement
- avoir pour point de depart
- se reposer sur
- etre fonde sur
- etre construit sur
La tu as repondu toi-meme a la question en identifiant deux sens possibles de "leadership", montrant par-la que ce terme est flou et gagne a etre remplace par des termes francais plus precis. Il y en a encore d'autres: charisme, excellence, emulation… autant de nuances qu'on perd quand on remplace tous ces mots par l'unique "leadership".
[^] # Re: Ah les francais...
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 1ere partie: eviter de sous-estimer la competition sur le plan technique. Évalué à -2.
Je ne suis pas contre tous les anglicismes, c'est pour ca que je parlais de mauvais anglicismes, facon de reconnaitre qu'il en existe d'autres qui sont bons.
Un bon anglicisme enrichit la langue; un mauvais anglicisme l'appauvrit en compromettant ses qualites.
Une qualite importante de la langue francaise est sa precision, alors que l'anglais est souvent plus flou. Par la, un schema typique de mauvais anglicisme est l'importation du flou anglais dans la langue francaise. Galerie des horreurs:
- cool comme adjectif (je n'ai rien contre cool comme interjection)
- ca fait sens
- etre base sur
- leadership
Ces anglicismes sont mauvais parce qu'ils sont moins nuances que les expressions francaises preexistantes.
[^] # Re: Ah les francais...
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 1ere partie: eviter de sous-estimer la competition sur le plan technique. Évalué à -6.
Je ne comprends pas ton commentaire: apparemment tu connais bien mieux la langue que moi tu tu as vu une erreur que je ne vois pas dans ce que j'ai ecrit. Pourrais-tu dire plus specifiquement ou est l'erreur?
Je ne comprends pas non plus ta pique sur le 'deprecated'. Fais-tu reference a un anglicisme que j'aurais commis? Lequel?
# Ah les francais...
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 1ere partie: eviter de sous-estimer la competition sur le plan technique. Évalué à -10.
Bon, les petits gars. On va passer sur le fait que vos commentaires de fins lettres qu'offense l'absence d'accents ne sont eux-memes pas exempts d'erreurs de syntaxe et de typographie. Et que vous n'avez pas releve quelque chose qui aurait du plaire aux fervents defenseurs de la langue: l'absence de mauvais anglicismes.
Est-ce qu'on peut revenir au sujet?
[^] # Re: OSS: l'API est bonne
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 1.
Ben oui, evidemment, puisque l'API "Win32" en question, c'est DirectSound. Je n'avais pas encore vu quelqu'un nier que c'est mieux qu'OSS.
# OSS: l'API est bonne
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 5.
Quoi?!
A la rigueur, "OSS117 : l'API est bonne", ca pourrait faire un bon mot de passe. A part ca, on est bien d'accord qu'on parle de l'API "tout est un fichier et pour lire un son il suffit de l'envoyer sur /dev/audio" ? "Tout est un fichier" est l'un des principes inalienables d'UNIX decides un jour par un barbu dans les annees 70. Comme disait OSS justement, "vous vous en lasserez… va falloir se decider a grandir!"
[^] # Re: Bravo mais...
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Firefox et Thunderbird 13 sont sortis, Firefox Mobile ESR mis à jour. Évalué à 4.
Pour info, ce que tu demandes sur le regroupement des fenetres dans la fenetre principale est deja en cours de developpement! Dans Nightly, les telechargements sont deja integres dans la fenetre principale, et il y a une option (dans about:config) pour que les Preferences soient une page about: comme tu le suggeres, ca s'appelle les "in-content preferences". http://msujaws.wordpress.com/2012/05/10/in-content-preferences-are-now-available-in-firefox-nightly/
[^] # Re: Nombreuses autres ameliorations
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Firefox et Thunderbird 13 sont sortis, Firefox Mobile ESR mis à jour. Évalué à 6.
Bon alors on oublie texture-from-pixmap: meme quand c'est disponible, ca marche trop mal pour les cas d'utilisation d'un navigateur web moderne. Notre projet actuellement est d'arreter completement d'utiliser des pixmaps X et a la place de n'utiliser que 1) OpenGL et 2) du rendu purement logiciel (comme Chrome, d'ailleurs). Tu peux en fait deja experimenter ca dans Nightly en allant dans about:config et en mettant layers.acceleration.force-enabled=true et gfx.xrender.enabled=false, et ca te donnera de tres bonnes perfs WebGL mais on a encore quelques problemes de performance dans d'autres cas a regler avant de pouvoir activer ca par defaut.
# Nombreuses autres ameliorations
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Firefox et Thunderbird 13 sont sortis, Firefox Mobile ESR mis à jour. Évalué à 9.
Dommage que notre service de presse n'ait qu'une tres vague idee de ce que nous faisons, voici par exemple un compte-rendu des ameliorations dans la couche graphique dans Gecko 13:
http://benoitgirard.wordpress.com/2012/05/24/gfx-changes-in-firefox-13/
[^] # Re: Google fait de l'ouvert et du ferme aussi
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Sergey Brin dénonce les « cages dorées » de Facebook et Apple. Évalué à 6.
Il y a en effet bien des notions differentes d'"ouvert" et on a ici un cas typique chez Google: le code source est ouvert, mais pas la conception/gouvernance/direction. De notre point de vue a nous, ca n'a aucun interet que Native Client soit open source puisque l'idee meme nous semble mauvaise, nous semble saper les bases du Web portable et bidouillable, et nous semble non-necessaire au vu des avancees du HTML et du JavaScript ces jours-ci.
[^] # Re: Google fait de l'ouvert et du ferme aussi
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Sergey Brin dénonce les « cages dorées » de Facebook et Apple. Évalué à 6.
Une application Native Client, c'est du code machine (x86 ou ARM). Ce n'est pas quelque-chose que l'on peut en general, de facon raisonnable, recompiler pour une autre architecture. Il y avait un projet, "Portable Native Client", qui devait offrir une representation intermediaire (IR) portable pour supporter n'importe quelle machine client, mais ce projet a du plomb dans l'aile: ils voulaient utiliser l'IR du compilateur LLVM, ce qui est une mauvaise idee d'apres les developpeurs de LLVM.
D'autre part, JavaScript est, de nos jours un langage compile tout court. Ensuite on peut souhaiter qu'apparaisse une meilleure alternative comme representation intermediaire, mais en attendant, ca marche bien mieux que ce que croient beaucoup de gens: essaye ce lien dans Firefox 15 (Nightly) ou Chrome Dev/Canary, et clique sur "full screen". C'est un jeu C++ OpenGL trans-compile en JavaScript et WebGL, et ca marche a 50 FPS chez moi! (Dans Firefox Nightly sous Linux je conseillerais les options layers.acceleration.force-enabled=true et gfx.xrender.enabled=false pour avoir de bonnes perfs).
# Google fait de l'ouvert et du ferme aussi
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Sergey Brin dénonce les « cages dorées » de Facebook et Apple. Évalué à 8.
(Avertissement: je travaille a Mozilla) C'est sur que Google fait beaucoup de choses tres bien pour le Web ouvert, bien plus qu'Apple et a plus forte raison encore que Facebook. Par exemple, sur WebGL, l'equipe de Google fait un travail formidable. Mais Google est malin: ils font a la fois de l'ouvert et du ferme, comme ca, ils gagnent dans tous les cas. Par exemple, pour le futur des jeux video en ligne, Google pousse certes les standards du Web (HTML5, WebGL etc) mais ils poussent encore beaucoup beaucoup plus leur propre solution "Native Client" qui est en gros le retour du bon vieux plugin binaire avec certes une meilleure securite. Ils presentent ca comme un truc ouvert auquel tous les fabriquants de navigateurs sont invites a participer, mais bien evidemment que nous on n'a pas envie d'encourager le retour des plugins binaires, et bien evidemment les APIs de Native Client ont deja ete decidees et pas de la facon dont elles auraient ete decidees si on avait participe (portabilite insuffisante, par exemple).
# Ironie sur LinuxFR
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Le système de santé du Mozambique sera libre. Évalué à 9.
Sans commentaire.
[^] # Re: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2. Dernière modification le 22 février 2012 à 04:19.
Cette page n'utilise bien entendu pas WebGL, c'est une demo technologique pour IE9! Url en microsoft.com.
C'est bizarre qu'elle n'affiche rien chez toi, ca laisse supposer un gros bug de XRender.
Pour repondre a ton autre question, WebGL fonctionne sous linux depuis le debut (il y avait certes peu de pilotes autorises dans Firefox 4 et 5, probleme resolu depuis).
[^] # Re: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 3. Dernière modification le 21 février 2012 à 18:59.
Par exemple, cette page tourne beaucoup plus vite dans Firefox quand ton pilote XRender accelere bien les operations dont elle a besoin (marche bien sur NVIDIA proprio et ATI libre 'radeon' au moins):
http://ie.microsoft.com/testdrive/Performance/PsychedelicBrowsing/Default.html
Et puis l'etat des pilotes OpenGL n'est pas si mauvais du tout. Les pilotes Mesa progressent a tres grand pas.
[^] # Re: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 5.
On est bien d'accord! C'est pourquoi la situation est totalement absurde. Le concept est le meme, on a juste 2 implementation differents (pixmaps contre textures) et des frottements entre les 2.
Le seul truc qui ait jamais ete retire d'OpenGL c'est le vieux pipeline a fonctionnalite fixe. Au contraire, les fonctions utiles a la 2D sont un domaine ou du travail est fait cf par exemple l'extension NV_path_rendering.
Tous les systemes graphiques sont asynchrones, mais seul X11 pretend abstraire completement la presence d'un reseau entre le client et le serveur.
[^] # Re: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 5.
Pour (1) imagine par exemple qu'on a rendu un paragraphe de texte avec Cairo dans un pixmap. Pour le compositing OpenGL, on va avoir besoin de lire ce pixmap depuis OpenGL, ce qui necessite de l'interpreter comme une texture.
Pour (2), note que OpenGL, comme X11, est une architecture client-serveur, concue elle aussi pour bien marcher en reseau. Il est vrai que pour du rendu 2D en reseau, XRender permet d'aller plus loin qu'OpenGL, parce que dans le rendu 2D, tout ne peut pas toujours etre fait par OpenGL. Mais la bonne facon de resoudre ca est de continuer d'etendre OpenGL pour couvrir ces besoins (la 2D, c'est dur).
Pour (3), je n'ai pas dit que c'etait facile. Tu peux voir mon point 3 comme un argument soulignant le cout reel d'avoir une architecture asynchrone en reseau. Il ne faut pas se voiler la face, X a ete concu pour des reseaux et quand on fait tourner un serveur X dans son petit portable en local, on paye bel et bien un cout pour ca, aussi bien en termes de perfs pour l'utilisateur, qu'en termes de complexite/bugs pour le developpeur d'applications.
Pour (4), en effet c'est probablement un probleme des pilotes.
[^] # Re: Comment X penalise Firefox / Linux
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 3.
Je ne sais pas si d'autres personnes a Mozilla ont fait part de nos besoins aux devs de Wayland, mais c'est en effet quelque chose a garder en tete.
A priori, comme tous les autres systemes a part X11 (Windows, Mac, Android) font le boulot correctement, on n'est pas inquiets: les problemes de X11 semblent specifiques a X11. Sauf mon point 4 peut-etre, mais si c'est un probleme au niveau des pilotes, c'est orthogonal a X-contre-Wayland.