URL: https://linuxfr.org/users/tallion/journaux/html-5-geometry-encore-une-api Title: HTML 5 : geometry, encore une API? Authors: tallion Date: 2013年11月08日T03:20:28+01:00 License: CC By-SA Tags: html5 et géométrie Score: 10 NB: je suis plus que faillible (comme le montre la quantité astronomique de fautes dans mon texte) merci de m’excuser si je fais des raccourcis ou omets des détails ou encore si je me trompe dans ma réflexion (et n’hésitez pas à me corriger!), le but étant d’échanger et partager:) Présentation: ----------- Récemment, j’ai reçu un mail me parlant d’une [API pour la géométrie](http://www.w3.org/community/geometryapi/wiki/Main_Page) qui permettrait aux navigateurs d'être extrêmement rapide pour certains calculs courant pour la 3d ou autre. Je pense que l’idée est intéressante mais passe à côté du problème: en effet, le manque n’est pas une absence d’API en soit mais plutôt l’absence de performances suffisantes dans le navigateur pour certaines applications, applications qui requièrent généralement des calculs intensifs comme c’est le cas pour la 3D ou la vidéo. Mon opinion ----------- Les exemples qui me viennent à l’esprit sont le traitement sur des images ( reconnaissance de visages) ou la 3d (collisions, simplification de modèles 3D, simulations) et si on regarde de plus prêt les papiers publiés dans le domaine ainsi que les implémentations dans les bibliothèques spécialisées existantes, on s'aperçoit rapidement qu’avoir une simple API nous limite grandement...Même si par miracle l’API se transforme en un [eigen](http://eigen.tuxfamily.org/index.php?title=Main_Page) et/ou un [blas](http://fr.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms), le coût de développement et de maintenance restent conséquent pour un apport limité à quelques problèmes précis ou plutôt pour les conséquences d’un problème plus profond... Il me semble plus pertinent de penser à un système global répondant au besoin de performance qui permettrait aux développeurs de fournir ces bibliothèques plutôt que d’essayer de créer une API pour chaque besoin... surtout qu’on est potentiellement capable de l'adresser en javascript si on omet simplement la rapidité d’exécution ou la consommation mémoire. Alors l'API est elle inutile? ------------------------ Aujourd'hui, elle est utile mais demain... J'espère que nous aurons d'autres solutions qui permettrons aux experts de chaque domaine d'avoir leurs librairies. Tout n’est pas rose pour autant et avoir de la performance dans le navigateur n’est pas une simple copié collé de code: quand je parle de performance, nous pensons tous à [asm.js](asmjs.org) (sous ensemble js pour la performance),[dsp](http://people.opera.com/mage/dspapi/) (api de calcul parallélisable) ou encore [WebCL](http://www.khronos.org/webcl/)(GPGPU pour le navigateur ) pour combler ce vide, mais même si le deuxième serait une partie de la solution finale d’après moi, ni asm.js ni même WebCL n’apportent une réponse convenable aujourd’hui: Ceux qui ont essayé asm.js savent que la communication entre le javascript classique et le code asm.js n’est pas optimal. En effet,le coût d’un appel vers le javascript classique rend parfois difficile la création de bibliothèque pour la simulation si l’on souhaites des performances rivalisant avec le natif*. A noter que le problème n’est pas l’idée mais l’implémentation et qu’avec quelques modifications (autovectorisation?gestion des threads?), on arrivera probablement à une solution convenable, bien que ma satisfaction ne soit pas complète (j'en parlerai dans un autre journal?). Pour le WebCL, c’est légèrement différent, le langage C pour l’écriture du code se prête bien pour la haute performance (dans une certaine mesure), cependant la copie obligatoire entre le contexte javascript et le drivers OpenCL ajoute une latence non négligeable... Ainsi, sauf si il y a une réintroduction de la possibilité d'utiliser directement la mémoire du javascript (un mixe entre l’argument CL_MEM_USE_HOST_PTR d’openCL et le [_transferable_ html5](http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#transferable-objects) pour éviter les accès concurrents ), je ne vois pas comment ce dernier permettrait d’avoir des traitements 3d temps réels que le js d’aujourd’hui ne permet pas déjà. Voilà mon petit journal/troll du jour :-) Je ne serai pas beaucoup disponible donc si je ne réponds aux commentaires que mardi, veuillez me pardonner mais je suis toujours content d’échanger avec toi chère journal. *: En regardant rapidement, je pense que cela proviens de la manière dont la mémoire est protégée (sur x86, la mémoire est copié dans son propre process puis ils utilisent les memory segment), mais je n’ai pas effectué de tests approfondie pour savoir si c’est vraiment ca

AltStyle によって変換されたページ (->オリジナル) /