Benoit Jacob a écrit 217 commentaires

Effectivement, on dirait bien que Mozilla a un peu joué les Lucky Luke en sortant WebGL 2 avant que la spec soit officiellement ratifiée. Ceci dit, ça fait très longtemps que WebGL 2 est au stade expérimental (un excellent stagiaire avait écrit un bon bout d'implémentation et fait tourner une belle démo à l'été 2013) donc finalement il faut bien sortir tout ça un jour. J'espère juste que ça ne va pas créer de précédent ou de mauvaise volonté.

Julien: merci de ta reponse detaillee. Sans chercher a avoir le dernier mot, juste quelques commentaires:

Oui, en matiere de travail avec la communaute, le bureau de Paris est bien l'exception. C'est culturel; il y a toujours eu une atmosphere libriste dans ce bureau; mais malheureusement, ca n'est pas representatif de l'attitude des autres bureaux et de l'administration central, pour qui "communaute" n'est pas grand chose de plus qu'un buzzword a mettre pour garantir le renouvellement du statut "nonprofit" de la fondation. Je voudrais souligner le courage de certains membres du bureau Paris qui n'ont pas hesite, en prenant la communaute au serieux, a se mettre en conflit avec les RH californiens.

Sur les retombees positives de Firefox OS au niveau technologique: je ne les nie pas et je ne pense pas que ca contredise ce que je disais. Sur ce sujet, j'ajouterais simplement que des retombees similaires auraient pu etre obtenues, par exemple, en appliquant le principe de base de Firefox OS, qui est de faire toute l'UI en HTML+CSS, a Firefox lui-meme. En effet, Firefox est depuis plusieurs annees en train de deprecier XUL, une transition extremement couteuse aussi bien en temps de travail, qu'en impact sur la communaute. Or, depuis Gaia (interface de FxOS), Mozilla sait faire une interface complete en HTML+CSS. Je pense donc que le meme effort aurait pu etre investi pour faire, non un OS mobile, mais un nouveau navigateur de bureau, base sur HTML+CSS. (D'ailleurs il y a eu quelques tentatives allant dans ce sens, mais elles n'ont pas beneficie de 1% des moyens alloues a Gaia). Peu importe le detail; je veux simplement dire que faire un OS mobile n'etait pas necessaire pour mener a bien toutes sortes de projets ayant des retombees positives pour Mozilla, et meme que ces projets aurait pu etre tres similaires sans l'aspect OS mobile en soi.

Sur le fait que l'equipe Graphics etait particulierement exposee a Firefox OS: c'est vrai, mais ce n'est pas unique. La clique qui est devenue le "leadership" de Firefox OS, a fait partir, directement ou indirectement, ouvertement ou de facon perverse, legalement ou par des methodes de harcelement, des dizaines de personnes issues de diverses equipes. Pour n'en nommer que quelques-unes, les equipes JavaScript, Release Engineering, Performance, Mobile/Android, ont chacune perdu des membres de grandes valeurs, a cause de manoeuvres de cette faction.

Pendant la periode Firefox OS (2012-2014), Mozilla est passe d'environ 400 employes a 1000 employes. Firefox OS a ete de loin la premiere affectation de ces nouveaux arrivants; je dirais que probablement au moins 300 personnes ont du etre recrutees specifiquement pour Firefox OS, en particulier l'integralite du bureau de Taipei qui etait assez important (nettement plus de 100 personnes a lui tout seul).

De plus, pendant cette periode, de grandes parties de Mozilla qui avaient un role generaliste, ont ete mises a contribution, soit officiellement, soit officieusement, ce qui rend le decompte difficile. Par exemple, mon equipe travaillait sur la couche graphique (programmation OpenGL etc) de Gecko, donc une equipe generaliste et officiellement on ne dependait pas de l'organisation Firefox OS. Mais les pressions et les jeux de pouvoir etaient tels qu'on ne pouvait pas faire autrement que d'obeir aux ordres des chefs de Firefox OS, qui de fin 2012 a mi-2014 etaient vraiment tout-puissants.

Ca a eu des consequences directes sur la communaute, au-dela de l'entreprise. Dans mon equipe, on considerait comme notre devoir d'aider les membres non-remuneres de la communaute a se familiariser avec notre codebase, par exemple en les mentorisant sur des bugs interessants. Fin 2012, j'aidais environ 5 membres de la communaute sur notre plateforme technologique, quand j'ai du tout laisser tomber pour consacrer tout mon temps a Firefox OS. Je n'etais pas le seul. Du coup, Firefox OS a eu un effet nefaste sur le lien entre l'entreprise et la communaute, des 2012.

J'ai bosse 4.5 ans a Mozilla jusque fin 2014 et je pense que ce que tu dis est correct, et c'est difficile d'en dire plus avec les informations rendues publiques par Mozilla.

La face cachee de Firefox OS, c'est, en haut, des luttes de pouvoirs entre ambitieux degeneres, et en bas, des employes malmenes.

C'est vrai que l'une des consequences est une destabilisation de toute la communaute, et c'est vrai que c'est tres grave pour Mozilla. Malheureusement, les consequences sont tout aussi nefastes pour la structure interne de l'entreprise Mozilla. Je pense que lorsque viendra l'heure de faire le post-mortem de Mozilla, on dira que Mozilla avait survecu, bon-gre mal-gre, a toutes sortes d'erreurs et de projets foireux, mais que c'est bien Firefox OS qui l'aura condamne.

On est bien d'accord que dans le cas de la fenetre ayant le focus ou dans le cas d'une application plein ecran, le compositeur ne dessine rien.

On n'est pas d'accord là-dessus non plus: tu peux certes concevoir un compositeur qui porte directement à l'écran le contenu de certaines fenêtres, mais cela comporte de nombreux inconvénients car cela suppose de renoncer à appliquer tous types d'effets. Par exemple, beaucoup d'utilisateurs de Mac OSX se reposent sur sa capacité a redimensionner en permanence le contenu des fenêtres ("scaling"); sans parler de la transparence, etc. Donc Mac OSX n'applique clairement pas de circuit direct pour les fenêtres ayant le focus. Le cas générique est donc bien de dessiner un quad utilisant le framebuffer de la fenêtre comme texture.

ceci ne garantit en rien la fluidite reelle des animations, qui depend du positionnement de la geometrie dessinee dans la fenetre en fonction du temps reel d'affichage a l'ecran.

Alors la, je ne te suis pas du tout du tout ! En quoi le positionnement d'une fenetre va avoir le moindre impact sur les performances !?! Relis mes postes plus haut sur l'utilisation des plan hardware.

Ça y est, je crois que je vois l'un des malentendus: tu parles des animations du compositeur lui-même ("le positionnement d'une fenêtre"), je parle des animations dessinées par l'application dans le contenu de la fenêtre ("la geometrie dessinée dans la fenêtre").

Si tu relis ce que j'écris sur la qualité d'animation, ce n'est pas nécessairement (peut-être, peut-être pas) quelque-chose que l'on peut mesurer par un quelconque procédé logiciel. A priori, cela se mesure avec une camera qui filme physiquement l'écran a au moins 60 images par seconde. C'est réellement comme ca que l'on fait dans l'industrie quand on tient vraiment a garantir la qualite réelle d'animation, par exemple les constructeurs d'appareils mobiles ont généralement recours a cette technique. Bien entendu, c'est très coûteux.

Bien sur, il faut finir par dessiner un framebuffer. Je dis simplement qu'on peut ne dessiner que ce framebuffer final, directement a partir de command buffers fournis par les fenetres, plutot que de le dessiner a partir de framebuffers intermediaires fournis par les fenetres. Comme tu le dis,

Maintenant en quoi le probleme change si tu as un compositeur dans l'histoire, tu as juste deux etapes supplementaire.

Et ces etapes supplementaires rajoutent une dose de latence, non-constante, entre le moment ou les fenetres dessinent leur propre framebuffer en positionnant leurs objets animes, et le moment ou ces pixels atteignent l'ecran. C'est ca qui limite la fluidite des animations dans les fenetres, independamment des performances.

Le veritable probleme est donc bien de maintenir le maximum de stabilite dans la capacite de ton process a pouvoir pousser une frame toutes les 16ms.

Ce que je dis ici, c'est que garantir ceci ne garantit en rien la fluidite reelle des animations, qui depend du positionnement de la geometrie dessinee dans la fenetre en fonction du temps reel d'affichage a l'ecran.

Mince alors, c'est un dialogue de sourds. Tu parles essentiellement de performance; je ne parle pas de performance. Quand je parle de "coûts", je parle de latence et de qualité d'animation, et, au sens où j'ai défini ces termes dans mon journal, cela n'a rien à voir avec des performances, avec le nombre d'images par secondes etc.

Je dis simplement que, indépendamment des performances, la latence et la qualité d'animation sont limitées par le paradigme classique du framebuffer de fenêtre qui demande à chaque fenêtre de finaliser son contenu bien avant que ce contenu atteigne l'écran et, pire encore pour la qualité d'animation, avant même de pouvoir savoir avec précision quand ce contenu atteidra l'écran. Je ne vois guère d'intersection entre ce sujet, et les éléments que tu développes ici.

Merci pour ta réponse intéressante. Cependant je dois t'avouer que je ne vois pas de contradiction entre ce que nous disons.

Pour répondre littéralement à ton objection, "un buffer qui pourra etre utilise directement par le compositeur", certes, mais comment est-ce qu'un compositeur utilise ce buffer? Réponse: il l'utilise comme texture et il dessine un quad avec. Ce qui revient à faire une copie --- juste une forme un peu généralisée de copie, qui permet le genre d'effets qu'on voit dans les compositeurs de bureau d'aujourd'hui.

Mais je ne veux pas pinailler là-dessus, car ce n'est pas le point qui me semblait intéressant. Même sans aucune "copie", il y a tout un tas de coûts à demander aux fenêtres de fournir un framebuffer pré-rendu, comme j'essayais de l'expliquer dans mon journal: latence importante et non-constante qui rend difficile d'avoir des animations parfaitement fluides, ce qui entretient le besoin pour les applications graphiques exigentes de pouvoir contourner le système, voir la discussion ci-dessus sur les jeux 3D en plein-écran.

Je pense toujours que l'idée que je propose ici est la première à permettre des graphismes à faible latence et faible distortion d'animation (bonne fluidité) pour toutes les fenêtres, sans avoir à contourner le compositeur de bureau!

Je n'aurais pas dû mettre ce P.S. alors, car le but était justement d'éviter de laisser ce genre de commentaire faire dévier la conversation. Je ne voulais pas répondre à ce commentaire, mais difficile de faire autrement maintenant qu'il est "Évalué à 10 (+17/-0)".

Il n'y a pas quelque chose de magique dans la sécurité qui fait que c'est toujours sage de faire passer cet aspect en premier. Dans le cas présent, il y a tellement d'inconnues par ailleurs qu'on peut difficilement avoir une conversation précise sur les aspects de sécurité, pour le moment. Et dans la mesure où je vois un peu comment tout ceci pourrait prendre forme, cela ressemble à des situations similaires (en particulier le GPU process dans Chrome) qui marchent bien d'un point de vue de sécurité.

Pas forcément, non, il y a aussi des systèmes qui attaquent directement le hardware en fenêtré. On le voit avec des artefacts comme des rectangles noires ou l'impossiblité de bouger la "fénètre" de l'application.

Oh, bien sur, on peut toujours avoir des systemes qui poussent le court-circuitage jusqu'a introduire des bugs visibles comme ce que tu decris. Je pensais que l'avenement des compositeurs de bureau avait porte le coup de grace a ces systemes, car les bugs graphiques deviennent particulierement evidents, mais je veux bien croire qu'ils existent encore. Ce que je voulais dire, c'est que l'idee que je propose ici permet pour la premiere fois d'avoir tous les avantage du court-circuitage, en toute generalite meme dans une fenetre, sans aucun cout-circuitage, et donc sans bug.

De toute façon, pour une application opengl, les commandes sont transmises directement au driver, aucun serveur graphique ne traduit les commandes.

Le pilote OpenGL est un serveur graphique. Il en faut bien un, pour permettre a plusieurs applications (les clients) d'utiliser OpenGL (le serveur) en meme temps. C'est pourquoi OpenGL se positionne comme un systeme client-serveur. Concretement, quand une application fait un appel OpenGL, ca ne ressemble pas a ceci:

Application -> appel bibli client OpenGL (libGL.so.1) -> syscall ou mmio

mais plutot a ca:

Application -> appel bibli client OpenGL (libGL.so.1) -> construction d'un command-buffer -> plus tard, envoi du command buffer au pilote graphique cote noyau -> mmio

C'est l' "entrecroisement" dont je parle dans le journal. Les applications OpenGL utilisent bien directement la carte graphique, au sens où elles communiquent directement avec son pilote. Mais le résultat est traditionnellement un framebuffer, qui va devoir être soumis au serveur d'affichage. A moins que l'application soit plein-écran et que le pilote sache court-circuiter le serveur d'affichage dans ce cas, voir plus haut, ce qui est la raison traditionnelle pour laquelle les applis en plein écran sont plus fluides (sur certains systèmes).

Si j'ai bien compris (ce qui est loin d'être sûr), il s'agirait de faire le buffer bitmap dans le serveur d'affichage au lieu de le faire coté client.

Oui, exactement!

Bien joué, bien joué, le coup de BeOS le faisait déjà il y a 15 ans. Quand je travaillais dans l'industrie du navigateur, on faisait la blague avec Opera, mais c'était la même chose.

Je suis d'accord avec ton analyse, l'idée générale qu'on envoie des commandes ou au moins quelque chose de structuré au serveur d'affichage existe depuis longtemps.

Ce qui a changé récemment, c'est que le monde des graphismes à bas niveau s'est plus ou moins standardisé autout de l'ensemble de fonctionnalités de OpenGL ES 2 (ou équivalent) comme "lingua franca". Par exemple, quand tu utilises un navigateur Web "moderne", tout ce que tu vois est passé par OpenGL ES 2 ou équivalent. Et comme ces commandes sont de bien plus bas niveau et bien plus généralistes que les primitives 2D à la XRender ou que les "surface trees" acceptés par certains serveurs d'affichage, et contiennent toute leur généralité (par définition, OpenGL représente à peu près ce que peut faire le matériel), on se dit que l'on pourrait rebooter tout ce cercles d'idées, et avoir un serveur d'affichage qui prend des commandes, mais cette fois-ci, des commandes de bas niveau à la OpenGL.

Ensuite, la coïncidence de la sortie de Vulkan qui offre un ensemble de commandes bien nettoyé et un système de command-buffers, rajoute une raison de plus de revisiter ce cercle d'idées aujourd'hui.

Bref c'est comme ça que je suis arrivé à l'idée décrite ici!

Voilà, exactement, c'est pourquoi un système à base de command buffers contient implicitement la possibilité, si on veut, de présenter un bon vieux framebuffer, sans avoir à faire quoi que ce soit en particulier pour supporter ce cas.

L'idée exprimée dans cet article est de permettre aux jeux en plein écran de contourner le serveur d'affichage. C'est une idée assez classique en soi, ce qui semble etre l'apport nouveau de cet article, c'est qu'il détaille une façon d'y arriver sur le bureau Linux libre actuel, alors que ce n'est a priori pas facile sur X ou Wayland. Mais je pense que cela fait longtemps que certaines plateformes ont des court-circuits pour les jeux en plein écran; je suis un peu surpris d'apprendre que les piles libres X/Wayland n'en avaient pas et je serais encore surpris si le pilote propriétaire NVIDIA n'offrait pas un tel court-circuit. En effet, l'implémentation de OpenGL + la couche d'interfaçage avec le serveur d'affichage (EGL ou GLX par exemple) a toutes les cartes en main pour traiter particulièrement les applications plein écran et décider si besoin de court-circuiter le serveur d'affichage: en fin de compte, c'est bien le pilote OpenGL qui détient les clés de la carte graphique.

Ce type de court-circuit permet effectivement aux jeux en plein-écran d'avoir un contrôle direct de l'affichage et élimine bien tous les problèmes liés au serveur d'affichage. Mais ce type de solution ne se généralise pas au-delà des jeux plein-écran. Les applications en mode fenêtre doivent encore passer par le serveur d'affichage, avec les problèmes qui vont avec. On a donc la situation actuelle, qui n'a pas vraiment changé en 20 ans, où les applications en plein écran marchent magiquement mieux que les applications en mode fenêtre.

L'idée que je propose ici permettrait, à ma connaissance pour la première fois, de généraliser ces avantages à toutes les applications, quel que soit leur type de contenu, et y compris en mode fenêtre, sans avoir à contourner le serveur d'affichage.

La messagerie interne de mozilla a longtemps ete sur Zimbra, mais ils sont en train de passer a Google, donc oui, ca va etre GMail. Ensuite chacun a toujours ete libre d'utiliser son client prefere, et il y a encore pas mal de gens sur Thunderbird, et ca peut tres bien continuer a l'ere GMail, meme si GMail a des fonctionnalites non standard qui ne sont pas parfaitement prises en charges par les clients IMAP comme Thunderbird.

Oui, c'est vrai 1, et oui, c'est triste, et oui, on aurait pu imaginer des choses plus réjouissantes que ça.

En tant qu'expat bossant sur un OS libre (Firefox OS) depuis l'étranger pour une entreprise principalement nord-américaine (Mozilla) je plussoie l'idée de relancer l'industrie française avec un projet volontariste d'OS libre!

L'article de Rue89 me semble inutilement critique à ce sujet; ses 5 points «contre» me semblent facilement réfutables eux-mêmes. En France on a plein d'étudiants et d'ingénieurs qui pourraient très bien faire le boulot, il manque simplement une volonté, et le courage de concurrencer frontalement les grands groupes américains («on ne pourra jamais battre Microsoft Apple Google sur son terrain!»). Aucune raison qu'on ne puisse pas, et un projet comme ça, même s'il finissait par échouer, aurait quand même un grand nombre de retombées très positives en termes de développement de compétences et de tissu industriel.

Pour réfuter les 5 points de Rue89:

1. Ce point se résume à «c'est trop tard pour lancer un nouvel OS quel qu'il soit, les utilisateurs sont déjà habitués à ce qu'ils ont». Réfutation: mis à part peut-être le problème des brevets logiciels (toujours pas reconnus en France à ce que je sache) rien n'empêche un nouvel OS d'imiter les OS existants sur les points essentiels qui vont permettre aux utilisateurs de se sentir à l'aise. Et même avec les brevets logiciels, on peut naviguer en eaux troubles (Firefox OS évite certaines fonctionnalités pourtant utiles…). L'important est d'avoir de bonnes équipes pour comprendre ce que veulent vraiment les utilisateurs en termes d'interface et de fonctionnalités (du bon marketing/design).

2. Ce point est intéressant, il soulève le problème de l'écosystème d'applications pour le nouvel OS. Intéressant qu'ils citent Mozilla dans la réponse. Dommage qu'ils ne disent pas qu'on a trouvé une bonne solution à ce problème pour Firefox OS: l'écosystème d'applications, c'est le Web. C'était pas évident au début pour Firefox OS car il manquait beaucoup d'APIs, mais on a écrit les spécifications et un nouvel OS pourrait simplement les implémenter et bénéficier immédiatement de toutes les application Web qui ciblent déjà Firefox OS. On me dit aussi que Tizen arrive sur le marché et suit aussi l'approche Web et implémente un grand nombre des mêmes specs…

3. C'est le problème de la poule et de l'œuf, ça se résout par une politique volontariste, c'est exactement pourquoi c'est une bonne idée que le gouvernement s'implique.

4. Un nouvel OS n'a pas à repartir de zéro, par exemple Firefox OS est parti d'Android, et en conserve des éléments importants (noyau, pilotes de périphériques, libc, quelques autres composants de bas niveau) tout en remplaçant la couche applicative (Java, etc) par sa propre sauce, en en customisant progressivement les éléments de bas niveau (noyau etc). Aujourd'hui, partir d'Android, ou d'un dérivé d'Android comme Firefox OS, ou pourquoi pas d'un dérivé de Meego (ce qu'a fait Jolla) pour un nouvel OS mobile me semble une évidence, quitte à s'en départir progressivement. Ça permet de démarrer le projet en un temps fini et de ne pas avoir à résoudre tous les problèmes d'un coup. En fait, c'est ça le grand bénéfice d'avoir plusieurs OS mobiles libres!

5. C'est juste du pinaillage sur les mots, de dire qu'un OS libre serait par définition international donc pas «made in France». Oui bien sûr qu'il sera international avec des contributeurs du monde entier. Mais en France, on pourrait avoir une entreprise (au moins initialement financée par l'Etat) qui embauche des ingénieurs en France et qui a des partenariats avec des universités en France. Ce qui aiderait spécifiquement à créer de belles opportunités en France et du tissu industriel local. Ensuite rien n'empêcherait d'autres pays de suivre, et ce serait très bien.

Il existe des dizaines de bibliothèques de rendu en JavaScript pouvant tirer parti de WebGL; la plus populaire est probablement three.js, mais une petite recherche t'en dégotera bien d'autres.

(Edit: oups, tu avais demandé des moteurs de jeu, pas juste des biblis de rendu. La réponse est encore oui il y en a et une recherche en trouvera, mais je n'ai pas de nom particulier qui me vienne à l'esprit. Si tu feuillettes le blog de learningwebgl.com/blog tu en verras beaucoup passer)

Note aussi que Emscripten est capable non seulement de compiler du C/C++ vers JavaScript, mais aussi de traduire les appels OpenGL en appels WebGL. C'est du sérieux, c'est ce que les moteurs commerciaux Unreal et Unity utilisent pour exporter des jeux entiers vers le Web.

Objections ô combien légitimes étant donnée la promesse faite par le Web de compatibilité universelle :-)

Ceci dit, on peut quand même relativiser:
- Les GPUs non-intégrés non-mobiles supportent entièrement le pipeline programmable requis par WebGL depuis que le GeForce 6 est sorti en 2004, il y a 10 ans, suivis par les Radeon l'année suivante je crois;
- Les GPUs intégrés d'Intel le supportent entièrement depuis les GMA X3000 en 2006;
- Sous Windows, Direct3D 9 est capable de tirer parti d'un support partiel, ce qui donne une accélération correcte dès le Intel GMA 945, encore plus ancien;
- Les appareils mobiles (téléphones) ont tous un GPU depuis quasi toujours, et ils supportent tous entièrement ce pipeline (car on a exprès choisi de se limiter aux specs d'OpenGL ES 2) depuis plusieurs années, même dans le bas de gamme (par exemple en Qualcomm, dès le Adreno 200; il faudrait redescendre sur des vieux Adreno 130 pour ne pas avoir ce support).

Quant aux problèmes de pilotes bugués, c'est sûr que ça a été un gros problème, mais l'avantage du développeur Web, c'est que le développeur de navigateur est forcé de gérer ce problème pour lui, par exemple en implémentant des contournements de bugs, et en poussant les fabricants de GPU à s'assurer qu'ils exécutent sans heurt la très grosse suite de tests officiels de WebGL.

Je travaille sur la partie graphique de Gecko et je trouve tout à fait crédible que le rendu par DOM d'un jeu soit plus rapide que le rendu par Canvas 2D.

Le canvas 2D est dérivé de CoreGraphics lui-même dérivé de PostScript. Ce type d'API n'a pas été conçu pour des graphismes en temps réel et encore moins sur GPU, et y est inefficace pour plusieurs raisons:
- API impérative consistant en une série d'opérations, mais qui ne ressemblent pas au type d'opérations qu'un GPU effectue, et donc difficile à traduire.
- Non-séparation du rendu et de la déclaration des ressources (par exemple drawImage() déclare que le canvas va accéder à une image et demande immédiatement son rendu).
- Existence de primitives intrinsèquement difficiles à optimiser sur GPU (courbes, texte…)
- Attente d'une très haute qualité d'anti-crénelage.

Alors qu'avec le rendu d'éléments DOM, tout est déclaré à l'avance, et la scène est décrite de façon déclarative, ce qui permet au navigateur de s'organiser pour optimiser son utilisation du GPU. Bien sûr, c'est encore assez tordu et il reste bien des façons de se planter, mais ça peut facilement être mieux que canvas 2D.

Dans Firefox sur X11, pour que le rendu DOM aille vite, aller dans about:config et essayer: layers.acceleration.force-enabled=true, gfx.xrender.enabled=false. On travaille à ce que ce soit activé par défaut d'ici à quelques mois. C'est déjà par défaut sur les autres plateformes.

Note: à la question de savoir quelle API Web serait vraiment efficace pour le rendu de jeux, la réponse est bien sûr WebGL :-) dans Firefox sur X11, à nouveau, essayer avec layers.acceleration.force-enabled=true.

LWN.net est quand même irremplaçable!

C'est un peu de la triche parce que c'est un site commercial, payant, avec des journalistes rémunérés capables de descendre très profond dans la technique, dont Jonathan Corbet qui est je crois un ancien dev du noyau. Mais bon, si la question est juste de savoir quel site offre le meilleur contenu, sans distinction entre communautaire et commercial, alors je ne peux pas faire autrement que de placer LWN.net en premier.

Comme je l'ai dit QtCreator et son aide en ligne est parfait.

C'est vrai: le Web manque de bon outils de développement.

Par contre question débogage de la couche de présentation, le Web est quand même formidable: imagine si tu pouvais inspecter tous les éléments graphiques de GCompris directement dans l'inspecteur DOM de ton navigateur!

Il est aussi plus simple de faire une interface dynamique qui s'adapte à la taille de l'écran en Qml.

C'est quand même un thème classique du développement Web («responsive design») et le comportement par défaut d'une page Web bien faite! Dans Firefox, il y a un outil conçu spécifiquement pour aider à ça.

Le découpage description de l'interface en Qml et logique du jeu en Javascript s'avère très efficace.

Et très similaire au cas d'une page Web!

GCompris est une porte d'entrée pour des étudiants qui veulent débuter sur un projet de logiciel libre. Il est important que l'écriture de code soit simple. En ce sens, Javascript en HTML5 implique une programmation asynchrone, très performante mais pas forcément idéale pour débuter en programmation.

C'est intéressant et vrai. D'un autre côté, JavaScript et le Web est probablement ce qu'un grand nombre d'étudiants apprend en premier de nos jours.

Au final la réalisation est basée sur un graphe de scène OpenGL avec des animations fluides et des particules ce qui ajoute un coté abouti à l'application sans que ce soit complexe à programmer. Pour animer mes poissons par exemple, il suffit juste de leurs donner des coordonnées et dire en combien de temps ils doivent les rejoindre.

Tu as exactement la même chose dans le Web avec les CSS Animations.

Pour la maintenance, j'ai plus confiance à m'appuyer sur une plate forme unique dont je peux contrôler la diffusion avec mon application plutôt que de devoir en permanence courir après les évolutions de chaque navigateur. Par exemple, mon application color_svg.html ne marche plus sur Firefox mais marche sur Chromium depuis une Ubuntu LTS.

C'est inquiétant. Normalement, dans le Web on prétend offrir une compatibilité quasi éternelle, en tout cas bien plus longue que les cycles d'environ 5 ans entre versions majeures de Qt. Il semble donc que tu as soit trouvé un bug dans Firefox (qui serait alors très utile à rapporter) soit ton application se reposait sur une fonctionnalité non-standard ou un bug (et alors ton navigateur aurait dû t'en avertir).

Oh, tu as déjà répondu à cette question ci-dessus.