Ma reponse est peremptoire, car c'est un fait pour toutes personnes qui a un peu une connaissance de comment fonctionne un navigateur web et ce que ca represente. Et oui, le W3C fait un effort pour limiter l'incoherence du bordel, c'est bien d'avoir de la bonne volonte et il leur en faut !
Maintenant pour etre plus serieux, le web n'a pas ete concu pour le monde de l'embarque, tu le remarques assez facilement sur tous les navigateurs web Android. Aucun ne va etre capable de mettre tes pages web en standby et ils sont oblige de les recharger completement. C'est juste un exemple. Il y en a d'autre et tu en trouveras par toi meme.
Le plus gros probleme du Web et surtout dans les dernieres annees et d'avoir de plus en plus pris la direction du "baremetal" en exposant des API de rendu direct. Cela impose de mettre toute la logique du rendu dans le JS et non dans le C. En prenant cette direction, ils ont certe plus de souplesse et ca evite de definir une API d'un toolkit de haut niveau (qui serait a mon avis impossible a faire standardise). Par contre, maintenant, cela impose une enorme logique en JS avec tous les problemes de performance que cela pose. Et dans ce genre de morceau de code, le controle de la memoire est absolument crucial.
C'est en fait le point le plus problematique et que les gens ne saississent pas facilement. Certe la quantite de memoire augmente exponentiellement, vive Moore. Par contre sa latence et sa consomation ne suivent pas du tout cette courbe. Pour faire simple, plus tu utilises de memoire plus tu vas devoir eviter les acces aleatoires (difficile quand tu es a faire du JS) et aussi plus tu utilises de memoire plus tu utilises de batterie. Tu peux compter un rapport 10 entre chaque niveau de la hierarchie memoire aussi bien pour la latence que pour la consomation. Enfin, si jamais tu atteinds la bande passante memoire limite de ta machine, ton CPU va attendre et consommer plus que si il pouvait juste dormir.
Devine quoi, faire un rendu graphique a l'ecran tombe exactement dans ces taches qui sont aux limites de la bande passante memoire et pour lequel tout cela compte terriblement.
Accessoirement pour proposer une alternative, c'est simple tu prends un toolkit graphique natif et tu mets du JS dessus. Tu eviteras tous ces problemes. KDE, Enlightenment et je crois aussi GNOME, on ca en stock.
Et sinon qui je suis pour juger, je suis un developpeur du projet Enlightenment et j'ai une petite idee de comment ca marche le monde de l'embarque et le rendu de graphisme optimise.
[^] # Re: Le web comme machine virtuelle ...
Posté par cedric . En réponse au journal Les vieux cons et le progrès.... Évalué à 10.
Ma reponse est peremptoire, car c'est un fait pour toutes personnes qui a un peu une connaissance de comment fonctionne un navigateur web et ce que ca represente. Et oui, le W3C fait un effort pour limiter l'incoherence du bordel, c'est bien d'avoir de la bonne volonte et il leur en faut !
Maintenant pour etre plus serieux, le web n'a pas ete concu pour le monde de l'embarque, tu le remarques assez facilement sur tous les navigateurs web Android. Aucun ne va etre capable de mettre tes pages web en standby et ils sont oblige de les recharger completement. C'est juste un exemple. Il y en a d'autre et tu en trouveras par toi meme.
Le plus gros probleme du Web et surtout dans les dernieres annees et d'avoir de plus en plus pris la direction du "baremetal" en exposant des API de rendu direct. Cela impose de mettre toute la logique du rendu dans le JS et non dans le C. En prenant cette direction, ils ont certe plus de souplesse et ca evite de definir une API d'un toolkit de haut niveau (qui serait a mon avis impossible a faire standardise). Par contre, maintenant, cela impose une enorme logique en JS avec tous les problemes de performance que cela pose. Et dans ce genre de morceau de code, le controle de la memoire est absolument crucial.
C'est en fait le point le plus problematique et que les gens ne saississent pas facilement. Certe la quantite de memoire augmente exponentiellement, vive Moore. Par contre sa latence et sa consomation ne suivent pas du tout cette courbe. Pour faire simple, plus tu utilises de memoire plus tu vas devoir eviter les acces aleatoires (difficile quand tu es a faire du JS) et aussi plus tu utilises de memoire plus tu utilises de batterie. Tu peux compter un rapport 10 entre chaque niveau de la hierarchie memoire aussi bien pour la latence que pour la consomation. Enfin, si jamais tu atteinds la bande passante memoire limite de ta machine, ton CPU va attendre et consommer plus que si il pouvait juste dormir.
Devine quoi, faire un rendu graphique a l'ecran tombe exactement dans ces taches qui sont aux limites de la bande passante memoire et pour lequel tout cela compte terriblement.
Accessoirement pour proposer une alternative, c'est simple tu prends un toolkit graphique natif et tu mets du JS dessus. Tu eviteras tous ces problemes. KDE, Enlightenment et je crois aussi GNOME, on ca en stock.
Et sinon qui je suis pour juger, je suis un developpeur du projet Enlightenment et j'ai une petite idee de comment ca marche le monde de l'embarque et le rendu de graphisme optimise.