Discussion :

[DonQuiche]

WebGL a toutefois quelques limitations :

• absence de tampon de sélection ;
• absence de textures 3D ;
• absence de geometry shader.

Et la plus grosse d'entre elles est malheureusement JS.

Je ne serais pas surpris si un jour tous les jeux étaient codés en WebGL (et plus généralement si toutes les applis étaient dispos sous forme de pages web). Mais ça n'arrivera que lorsqu'il sera possible d'envoyer un code de plus bas niveau que JS, par exemple via NaCl ou asm.js. Accessoirement il y aura aussi du boulot à faire sur le support des périphériques, des casques 3D aux manettes et joysticks. Enfin les cartes 3D doivent offrir une mémoire virtuelle et des anneaux de privilèges comme les CPU (c'est déjà le cas chez AMD avec HSA) pour alléger le poids du bac à sable aujourd'hui en place autour des appels webgl.

Mais sur le fond on en revient toujours à la même chose depuis vingt ans : le problème c'est JS. Quelles que soient les qualités de ce langage (ou pas), comme solution universelle imposée c'est un foutu boulet. Et les navigateurs doivent plus généralement devenir de vrais petits OS capables d'exécuter de façon sûre un code de plus bas niveau qu'aujourd'hui et d'offrir à des applis web universelles tout ce dont elles ont besoin.

Et, non, JS n'est pas aussi rapide que le C (sauf sur trois mini-benchmarks bidons). Non, les compilateurs JS ne savent pas faire de vaudou et ont atteint leurs limites (ou alors il faudra rendre la compilation extrêmement longue - plusieurs heures).

Allez, je vous laisse me moinsser. Mais j'ai raison.

[codec_abc]

Non mais tu es sérieux là? Tu penses vraiment que des boites comme Epic et Unity qui sont en très fortes concurrence sortiraient des démos à 3fps? Epic citadel tourne en moyenne entre 25 et 30 fps sur une machine bas de gamme. Si tu as des ralentissement alors le problème vient de TA machine, de TES drivers, de TES applications installées, de TES plugins... bref cela vient de TA machine cliente.

C'est peut-être vrai dans son cas (sans parler des performance qui sont quand même un cran en dessous en WebGL par rapport à de l'OpenGL C/C++) mais le problème du WebGL c'est qu'il va avoir beaucoup de mal à être universel. Le Web tel qu'il ait aujourd'hui fonctionne bien sur une multitude de périphérique différent. Or le WebGL est tributaire des drivers OpenGL (ou directX avec Angle) et la plupart des drivers ne sont pas sans défaut. Tu peux regarder l'article des développeurs de dolphin qui testent à peu près tous les drivers OpenGL desktop disponible pour le grand public. De plus, il semble que sur mobile le phénomène soit encore pire. Donc finalement, le problème du "chez moi ca marche pas" risque d'être assez fréquent en WebGL suivant le hardware et/ou l'OS.

La même démo tourne en natif desktop à 48fps sur les mêmes machines, les perfs sur donc tout à fait acceptable pour un jeu dans un canvas HTML5.
Ton oeil voit à peine la différence au dessus de 30fps, après c'est juste une question de fatigue et de confort du regard, peu de moteur desktop peuvent se venter de faire du 60FPS continue sur PC et console. 30FPS ici c'est un très bon boulot.

Déjà, on est pas loin d'avoir un facteur 2 entre les chiffres que tu donnes ce qui est énorme de mon point de vue. De plus, faut arrêter avec le "30 fps ca suffit". La 3D temps réel n'est pas comparable un film, et la première doit donc avoir beaucoup plus d'images par seconde pour paraitre fluide. En 3D temps réel, on voit largement la différence à l'œil nu entre 30 et 60 fps. Dans certains cas 30 fps peuvent suffire, mais dans d'autres (notamment le jeux vidéo) ce n'est pas suffisant. Personnellement, en dessous de 45-50 j'ai souvent des maux de tête au bout de 10 minutes. Du coup, je maintiens mon avis que le WebGL c'est bien, mais pas pour tout. Surtout dans l'immédiat.

[DonQuiche]

Epic citadel tourne en moyenne entre 25 et 30 fps sur une machine bas de gamme. Si tu as des ralentissement alors le problème vient de TA machine, de TES drivers, de TES applications installées, de TES plugins... bref cela vient de TA machine cliente.

Epic Citadel accomplissait cette performance grâce à asm.js, qui n'est supporté que sous Firefox.
J'utilise l'imparfait car la démo a été retirée, probablement parce qu'elle faisait pâle figure sous Chrome, IE, Safari et Opéra.

Ton oeil voit à peine la différence au dessus de 30fps, après c'est juste une question de fatigue et de confort du regard, peu de moteur desktop peuvent se venter de faire du 60FPS continue sur PC et console. 30FPS ici c'est un très bon boulot.

Ton oeil verra tout de même la différence entre 30 et 60 ips mais surtout il percevra significativement et désagréablement toute variation brutale du framerate. Par exemple parce que le ramasse-miettes s'est mis en route.

[Astraya]

Epic Citadel accomplissait cette performance grâce à asm.js, qui n'est supporté que sous Firefox.
J'utilise l'imparfait car la démo a été retirée, probablement parce qu'elle faisait pâle figure sous Chrome, IE, Safari et Opéra.

Oui je suis d'accord, il est compiler avec Emscripten. Mais ici le problème de perf n'est pas WebGL. C'est juste que asm.js est performant sur Firefox et pas performant sur chrome voir pas supporter sur les autres. C'est en aucun cas un problème à WebGL mais à la partie JavaScript qui est, il faut le dire, du grand n'importe quoi à cause de la guéguerre entre les navigateurs. Dans ce cas ( je précise bien dans ce cas uniquement ) WebGL fonctionne parfaitement, JavaScript non car c'est LE bottleneck. Chrome à voulu sortir son NativeClient, qui ne fonctionne que sous Chrome. Mettez du WebGL sous Chrome avec NativeClient ça fonctionne bien.
Le problème n'est pas WebGL, se sont les couches qui ne sont pas la de responsabilité de Khronos group le problème.

Pour l'histoire des 30fps et 60fps il y a une différence lors de mouvement rapide sur l'image. Ce qui est vraiment pas important si on prend en compte deux facteurs:
1 - La cible des joueurs: un "gamer" qui veux ces 60FPS car il y passe 3 heures dessus ne jouera pas sur un navigateur, donc 30FPS sont à l'heure actuelle ( par rapport au client ) suffisants.
2 - Vous voulez un Call of Duty ou Modern Warfare sur votre navigateur? ok... Mais je pense que le principale problème est plus le téléchargement des 60Go de données que la rapidité d'affichage.

Ici, je comprends que certains pleure de ne pas avoir de 60FPS, mais maintenant il faut réfléchir sur l'utilité des 60FPS sur un navigateur, a qui cela profite? Va-t-on vraiment faire un need for speed su navigateur? il met les datas en cache? j'imagine bien la gueule de la RAM...

[jean_kevin_musclor]

Non mais tu es sérieux là? Tu penses vraiment que des boites comme Epic et Unity qui sont en très fortes concurrence sortiraient des démos à 3fps?

J'en ai la preuve sous les yeux.

Epic citadel tourne en moyenne entre 25 et 30 fps sur une machine bas de gamme.

Je viens d'exploser de rire.

Ton oeil voit à peine la différence au dessus de 30fps

Je viens encore d'exploser de rire. Un truc qui tient même pas les 60 fps sur les machines high-tech de ta boîte, ça t'étonne que ça rame à 3 fps sur l'ordinateur de prolo de l'internaute moyen ? hé bien pas moi

De plus tu devrais plus te renseigner sur Emscripten... Tu dis (c++ -> assembleur -> javascript) moi je te dis (c++ -> LLVM -> javascript).

C'est la même chose. T'as déjà jeté un oeil à du js emscripten ?

Je lis des trucs complètement aberrants dans ce topic.

Je lis par ci par là que javascript est aussi rapide que c++ et que le webgl serait aussi rapide que l'opengl... on ne parle bien que de ce qu'on connaît, quand on parle de ce qu'on fait semblant de connaître on est sûr de ne dire que des âneries

Vous feriez mieux de mettre les mains dans la mécanique au lieu de vous inventer un savoir technique en répétant les ragots marketing d'internet. (encore pour ça faut il avoir la motivation de s'intéresser à ce qu'on fait, chose assez rare dans le milieu du web il est vrai)

Y'a qui ici qui a mis sérieusement les mains dans le webgl au lieu de roupiller sur three.js et unity ? qui s'est réellement tapé les tests de perf, benchmarks, % cpu avec règle de trois vers machine bas de gamme, tester un shader ligne par ligne sur quatre navigateurs ? qui a réellement testé emscripten en rentrant dans le détail du code ? vu le niveau de la discussion je dirais personne

Ca vous apporte quoi sérieusement de colporter des mensonges à part trouver des excuses pour faire fuir les internautes avec des cpu-killer ?

[the Hound]

Je lis des trucs complètement aberrants dans ce topic.

Je lis par ci par là que javascript est aussi rapide que c++ et que le webgl serait aussi rapide que l'opengl... on ne parle bien que de ce qu'on connaît, quand on parle de ce qu'on fait semblant de connaître on est sûr de ne dire que des âneries

Vous feriez mieux de mettre les mains dans la mécanique au lieu de vous inventer un savoir technique en répétant les ragots marketing d'internet. (encore pour ça faut il avoir la motivation de s'intéresser à ce qu'on fait, chose assez rare dans le milieu du web il est vrai)

Y'a qui ici qui a mis sérieusement les mains dans le webgl au lieu de roupiller sur three.js et unity ? qui s'est réellement tapé les tests de perf, benchmarks, % cpu avec règle de trois vers machine bas de gamme, tester un shader ligne par ligne sur quatre navigateurs ? qui a réellement testé emscripten en rentrant dans le détail du code ? vu le niveau de la discussion je dirais personne

Ca vous apporte quoi sérieusement de colporter des mensonges à part trouver des excuses pour faire fuir les internautes avec des cpu-killer ?

Et ça t'apporte quoi d'insulter les gens comme ça ? Les gens n'ont pas le droit de débattre ? Il n'y a que toi qui a raison ?
T'as fait du WebGL alors t'es un expert et les autres c'est de la m**** ? Tu crois être le seul à tester des technologies ?
Qui es-tu pour juger du niveau de la discussion, ou des personnes ici présentes ?

Quel est ton intérêt à participer au débat si tu ne respectes pas l'avis des autres ?

Au fait, c'est pas parce que ta machine fait tourner X à 3 fps que c'est la Vérité Absolue.

[jean_kevin_musclor]

Répétez après moi l'excuse perpétuelle pour fourguer de la camelote: c'est la faute à la machine, c'est la faute à la machine, c'est la faute à la machine, c'est la faute à la machine, c'est la faute à la machine, c'est la faute à la machine... à force de répéter la disquette les gens vont finir par y croire.

Excusez-moi ne ne pas cautionner ce comportement malhonnête.

Inutile d'aboyer en meute sur le web pour essayer de sauver la réputation d'une techno médiocre, l'internaute n'est pas dupe il voit que ça rame. je rappelle que l'internaute moyen surfe sur téléphone mobile pourri et pas sur le laptop à 5000$ de votre patron qui n'y voit que du feu jusqu'au jour où il lit les stats de visite qui se cassent la figure

ça ne sert à RIEN d'accuser les internautes d'avoir des machines de prolos, vous êtes sensés vous adapter à leurs machines, et pas l'inverse

[the Hound]

Ça reste préférable à un raisonnement du style : y'a une techno X, ça marche pas chez moi, mais c'est pas la faute à la machine, donc c'est celle des devs, donc X c'est de la daube et les mecs qui l'ont dev aussi, et aussi ceux qui soutiennent cette techno. Donc ils ont tort, il faut absolument que je le fasse comprendre aux autres en les insultant.

[jean_kevin_musclor]

La vérité c'est qu'on a pas le choix vu que sur les browser y'a rien d'autre que le javascript. Mais est-ce une raison valable à ce déballage de mauvaise foi totale pour essayer de faire croire à qui veut l'entendre que le javascript est le summum de la technologie ? On est plus dans l'objectivité là mais dans l'art de faire de nécessité vertu.

Ca n'est pas parce qu'on est obligé de travailler avec un langage pourri qu'il faut inventer des histoires pour se persuader que c'est génial.

En tout cas merci de nous faire rire... le syndrôme je me prends pour le roi du pétrole parce que j'ai trouvé un truc qui permet de faire facilement de la 3d, d'autres sont passés par là avant vous...

Pour l'instant le webgl c'est juste un gadget qui sert à faire joli dans un coin de la page web et ça n'a à mon avis pas la vocation de servir à autre chose.

Il faut savoir s'en contenter au lieu de gaspiller la r&d dans des expériences foireuses de portage unreal unity...

Quoique dans le cas de unity je suis sûr qu'ils l'ont fait exprès pour prouver la supériorité de leur plugin. Quand aux portages navigateur de unreal, quake, etc, ils ont surtout prouvé que flash plugin rendait la 3d dix fois plus vite.

Passer de 60 fps à 3 fps c'est exactement les résultats attendus, le javascript étant officiellement 20 fois plus lent que le c++.
60 / 20 = 3 , étonnant non ?

Javascript est structurellement lent pour tout un tas de raisons. Déjà parce qu'on a préféré faire un langage facile plutôt qu'un langage rapide, ensuite parce que les browser sont des applications bureautique pas du tout structurées pour du multimédia, et enfin surtout parce qu'ils n'ont pas envie de claquer des trop gros budgets pour des programmes gratuits.

Pour information chez google ils ont laissé tomber le javascript et les prochaines applications webgl sur chrome devront être programmées dans un nouveau langage exotique que personne ne veut apprendre. Ca s'annonce bien parti... ils sont pas prêts de tuer les plugins 3d ^^

[Astraya]

Salut,

Je ne vais pas continuer à débattre avec une personne qui semble connaitre sur le bout des doigts ces technos.

Mais renseignes toi sur les personnes avec qui tu débats avant de lancer ta rage comme ça. On ne connait pas tous sur le bout des doigts tout sur tout sur les technos et langages et même les experts aujourd'hui apprennent des choses.

Vous feriez mieux de mettre les mains dans la mécanique au lieu de vous inventer un savoir technique en répétant les ragots marketing d'internet. (encore pour ça faut il avoir la motivation de s'intéresser à ce qu'on fait, chose assez rare dans le milieu du web il est vrai)

Je ne viens pas du milieu du web mais du jeu vidéo professionnel.

Y'a qui ici qui a mis sérieusement les mains dans le webgl au lieu de roupiller sur three.js et unity ? qui s'est réellement tapé les tests de perf, benchmarks, % cpu avec règle de trois vers machine bas de gamme, tester un shader ligne par ligne sur quatre navigateurs ? qui a réellement testé emscripten en rentrant dans le détail du code ? vu le niveau de la discussion je dirais personne

Je me suis arrêté à "Unity". Tu penses que le développeur fait du unity? le développeur développe du Unity, celui qui fait du JavaScript dans Unity utilise Unity. Faire un script et faire un moteur ce n'est pas jouer dans la même court, désolé. Je ne dis pas par là que faire un jeu avec Unity et scripter en JavaScript est simpliste, je respecte le travaille de ceux qui font ça.

Penses-tu faire du code tellement performant que le bottleneck est WebGL et non pas ton architecture.

ça ne sert à RIEN d'accuser les internautes d'avoir des machines de prolos, vous êtes sensés vous adapter à leurs machines, et pas l'inverse

Qui à dis que tu avais une machine de "prolos"? WebGL tourne sur un téléphone Android, ici le problème est software chez toi, donc déjà tu es hors sujet. Tu peux avoir 500 processeurs si ton software est leaker/lourd/monothread ça ne changera rien.

Ca n'est pas parce qu'on est obligé de travailler avec un langage pourri qu'il faut inventer des histoires pour se persuader que c'est génial.

Je comprends pas là... Dans d'autre poste tu dis que JavaScript est une bonne techno pour apprendre...
J'ai également noté autre chose sur le fait que JavaScript n'est pas objet plus avant dans la discussion.. Alors tu devrais sans doute écrire à la MDN pour leur dire de supprimer cet article -> https://developer.mozilla.org/fr/docs/Web/JavaScript/Guide/Utiliser_les_objets

Pour l'instant le webgl c'est juste un gadget qui sert à faire joli dans un coin de la page web et ça n'a à mon avis pas la vocation de servir à autre chose.

Donc les outils de force vente, le seriousgame n'existe pas.

Il faut savoir s'en contenter au lieu de gaspiller la r&d dans des expériences foireuses de portage unreal unity...

Tu connais leur stratégie de développement peut-être. L'investissement également. La R&D.

Passer de 60 fps à 3 fps c'est exactement les résultats attendus, le javascript étant officiellement 20 fois plus lent que le c++.
60 / 20 = 3 , étonnant non ?

Si c'est ça les benchmarcks alors ma petite nièce peut en faire

Pour information chez google ils ont laissé tomber le javascript et les prochaines applications webgl sur chrome devront être programmées dans un nouveau langage exotique que personne ne veut apprendre. Ca s'annonce bien parti... ils sont pas prêts de tuer les plugins 3d ^^

https://developer.chrome.com/native-client
https://developer.chrome.com/native-...cation-gallery

Il faut voir le navigateur comme une machine différente avec ses technos et spec différente. Tu veux le faire partout efficacement? alors faire ne sorte que ton engin soit compilable avec NativeClient pour Chrome, Emscripten pour Mozilla et plugin pour les autres. C'est exactement comme développer pour Wii, PlayStation et Xbox. Tu dois adapter le code à la cible.

[SylvainPV]

Pour information chez google ils ont laissé tomber le javascript

[jean_kevin_musclor]

Je ne viens pas du milieu du web mais du jeu vidéo professionnel.

Donc tu es bien évidemment la personne la mieux placée pour parler de la programmation web.

J'aime bien ton raisonnement... moi j'ai programmé des moteurs de jeux donc moi j'ai la plus grosse donc moi je me permets de me prévaloir de tous les autres métiers.
lol

[DonQuiche]

C'est la même chose. T'as déjà jeté un oeil à du js emscripten ?

Si je suis plutôt d'accord avec tes propos et notamment avec l'inadéquation de JS (mais pas avec l'outrecuidance et le manque de nuances avec lequel tu assènes tes propos), concernant emscripten j'attire ton attention sur le fait que les 20-30 ips étaient obtenues sur Firefox grâce à asm.js, qui est en fait une sorte de code assembleur en JS, une sorte de bytecode d'ausi bas niveau que le x86 si tu préfères.

Si le navigateur est optimisé pour la techno (Firefox) il va reconnaître ces instruction spéciales et les remplacer par les instructions assembleur correspondantes, produisant un code final équivalent au code assembleur orginal (à quelques détails près). Si le navigateur n'est pas optimisé, alors ces instructions sont exécutées comme des fonctions et l'ensemble se comporte comme un émulateur x86, ce qui est forcément très lent. Chrome offre quelque chose de similaire avec pNaCl.

[jean_kevin_musclor]

Ma thèse est simple: le js est lent point barre.

Les petits rigolos qui s'amusent à clamer le contraire en accusant les machines, c'est de la mauvaise foi totale. Ils doivent bien se marrer derrière leur clavier à raconter sciemment n'importe quoi.

[Astraya]

Donc tu es bien évidemment la personne la mieux placée pour parler de la programmation web.

J'aime bien ton raisonnement... moi j'ai programmé des moteurs de jeux donc moi j'ai la plus grosse donc moi je me permets de me prévaloir de tous les autres métiers.
lol

Est-ce que j'ai l'air de me vanter? Si un comptable vient t'expliquer comment déclarer tes impôts il se la pête?

Arrête de te faire passer pour un rageux qui peste contre tout et tout le monde. Ici c'est un forum d'échange, on est là pour échanger. Si tu viens pour hurler ta rage tu n'a rien à faire ici.
Je te donne mon avis et mon expérience pour que tu comprennes pourquoi je dis ça. Maintenant libre à toi de rester dans ton délire. Je m'arrête la pour t'aider à comprendre.

[jean_kevin_musclor]

Astraya te rends tu compte que ton discours est illogique de A à Z ?

Si j'ai bien suivi ton raisonnement: moi j'ai fait des jeux vidéos alors c'est moi le plus fort qui ai la plus grosse alors c'est à moi d'expliquer aux webdev comment on fait un site internet, je l'sais mieux.

C'est clair que le milieu du jeu vidéo c'est vachement eux les mieux calés pour se servir du webgl, y'a qu'à voir les démos catastrophiques de uinty unreal.

C'est pas le même métier, comparons ce qui est comparable.

Tu veux un avis d'experts ? L'équipe de google en personne ils disent eux-mêmes que le js ça rame. Mais t'as raison les programmeurs de super mario connaissent mieux qu'eux les métiers du web...

[DonQuiche]

Ma thèse est simple: le js est lent point barre.

Le JS, oui, pas un flux asm.js codé en JS mais recompilé directement en assembleur par Mozilla. Ce n'est pas du JS, c'est de l'assembleur encodé en JS que le navigateur doit reconstituer.

Le code produit est à peu près aussi rapide que l'assembleur original (la différence vient des mécanismes de sécurité mis en place). C'est d'ailleurs le but. Et c'est là-dessus que s'appuyait la démo de l'Unreal Engine 3 (malheureusement retirée du fait de sa lenteur sur les autres navigateurs).

[jean_kevin_musclor]

Ben oui, on est sensés s'adapter à tous les navigateurs.

Or là ils sont en train de partir chacun dans leur direction, mozilla avec son compilateur c++, chrome qui crée son propre langage exotique, iexplorer qui suggère plutôt le silverlight... bref c'est le bazar et les agence web ont autre chose à fiche que de porter leur pub de bagnole 3d dans trois langages différents. Alors tant pis il faut se contenter du standard javascript de merde qui rame.

[DonQuiche]

Or là ils sont en train de partir chacun dans leur direction

Oui, comme pour chaque innovation sur le web avant qu'elle ne devienne standard.

Alors pour l'instant les agences web ont effectivement mieux à faire mais certains éditeurs peuvent dores et déjà cibler tous les appareils Android et 60% des PC via Firefox/Chrome (une exigence qui peut être acceptable pour un jeu). Tout ça avec le même code (par exemple emscripten peut générer du pNaCl comme de l'asm.js).

Et puisque dans le cadre d'une discussion sr l'avenir du webgl il me semble important de pouvoir se projeter... Nous ne sommes pas en train de discuter d'un projet à livrer dans trois mois.

Bref, oui, le problème c'est JS. Oui il faut vite que l'industrie s'accorde sur un standard bas-niveau. Mais ça vient.

[the Hound]

Si j'ai bien suivi ton raisonnement: moi j'ai fait des jeux vidéos alors c'est moi le plus fort qui ai la plus grosse alors c'est à moi d'expliquer aux webdev comment on fait un site internet, je l'sais mieux

Mais on est au top de l'hypocrisie là ...