Journal Un environnement d'exécution Flash en ... Javascript

Posté par  .
Étiquettes :
16
15
jan.
2010
Un environnement d'exécution Flash, libre, entièrement écrit en Javascript.
Ça marche même dans le navigateur (pourtant limité) tournant à l'intérieur de Second Life.

J'ai tester les démos vite fait avec firefox et chromium.
Et CHROMIUM s'en sort nettement mieux.

http://paulirish.com/work/gordon/demos/

Après l'intégration vidéo, l'accélération vidéo 2d et 3d, et googles gears, que reste t'il d'utile au plugins d'antan.

Il me semble que l'évolution du navigateur en client riche prend de la vitesse.

Ps: a tester vraiment avec le navigateur de google pour voir vraiment la différence de performance avec firefox , c'est étonnant.
  • # réponse

    Posté par  . Évalué à 6.

    que reste t'il d'utile au plugins d'antan. ?

    la vitesse d'exécution ? :)

    Blague à part, c'est étonnant comme produit, mais est-ce que c'est capable de s'interfacer dans un navigateur existant n'utilisant pas flash, et de lire des jeux en flash par exemple ? Ou alors est-ce qu'il faut implicitement faire des ajustements pour intégrer le fichier flash et que c'est "juste" limité à quelques animations ?

    Concrètement, est-ce que cela permettrait par exemple de lire le menu en flash d'un site qui aurait eu la mauvaise idée de faire un tel menu ?

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: réponse

      Posté par  . Évalué à 2.

      Et puis le son aussi.

      BeOS le faisait il y a 20 ans !

    • [^] # Re: réponse

      Posté par  . Évalué à 1.

      Bonjour,

      Ca doit pouvoir le faire en automatique sous firefox avec un petit script greasemonkey ...

      Par contre je pense que le support reste encore très limité.
  • # Et ça fait quelle taille dans les pages à charger?

    Posté par  . Évalué à 10.

    Nan paske autant flash, on sait déjà que c'est lourd avec un plugin, mais si en plus faut télécharger un interprêteur js sur chaque page, ça va pas améliorer l'expérience utilisateur des masses...

    M'enfin bravo pour la partie technique.

    A quand le kernel linux réécrit en js??
    • [^] # Re: Et ça fait quelle taille dans les pages à charger?

      Posté par  . Évalué à 7.

      A quand le kernel linux réécrit en js??

      Pour Google OS ?
      • [^] # Re: Et ça fait quelle taille dans les pages à charger?

        Posté par  . Évalué à 2.

        Déjà que l'interface de GNOME 3.0 qu'est GNOME Shell est écrite en partie en JS...

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Et ça fait quelle taille dans les pages à charger?

          Posté par  . Évalué à 2.

          Déjà que j'étais dubitative sur l'ergonomie de Gnome Shell...

          Mais où sont passés les Docks et les Clips à la WindowMaker/*Step ?
        • [^] # Re: Et ça fait quelle taille dans les pages à charger?

          Posté par  . Évalué à 8.

          Rappelons que GNOME Shell *nécessite* (ce n'est pas une option, comme on pourrait se passer de compiz) GLX (ou openGL, ou que-sais-je), et ne fonctionne donc pas sans accélération graphique, avec un bête driver vesa. Ajoutons que Shell sera incontournable dans GNOME3.

          C'est pas si mal que ça en fait XFCE.
          • [^] # Re: Et ça fait quelle taille dans les pages à charger?

            Posté par  . Évalué à 1.

            Pour l'instant, rien n'est encore décidé réellement pour GNOME 3, on ne sait même pas si ce sera la 2.30 ou la 2.32.

            Cependant, les deux interfaces risquent a-priori, de cohabiter, ce qui n'est pas optimal, mais permet au moins le choix. Je vous laisse lire http://live.gnome.org/GNOME3Myths où il est expliqué entre autres que le panel et Metacity seront toujours présents.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Et ça fait quelle taille dans les pages à charger?

              Posté par  . Évalué à 0.

              "Clutter has been used on everything from mobile phones to computers, and almost any computer built in the last 5 years will be able to run the new GNOME 3.0 user interface"
              #+*@{/%!

              "The GNOME 2.x panel and Metacity (the window manager) will still be available and downstream distributions such as Fedora, openSUSE and Ubuntu will have the option to include them in their distribution. "
              Aha oui merci, c'est comme "tu peux continuer à utiliser KDE3 [qui est beaucoup moins [voire plus du tout] maintenu] plutôt que KDE4, des distros le packagent encore".
              • [^] # Re: Et ça fait quelle taille dans les pages à charger?

                Posté par  . Évalué à 2.

                Bah je comprends will still be available comme toujours disponible, et je suppose qu'il sera au moins maintenu. L'idée, c'est que l'API ne bouge plus et que de nouveaux applets pourront toujours apparaître.

                Ça serait dommage, et disons-le idiot, de se débarrasser d'outils comme la Deskbar ou Hamster qui ont intégré GNOME il y a quelques versions.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Et ça fait quelle taille dans les pages à charger?

                  Posté par  . Évalué à 1.

                  "Ça serait dommage, et disons-le idiot, de se débarrasser d'outils comme la Deskbar ou Hamster qui ont intégré GNOME il y a quelques versions."
                  Parce que pour KDE4, c'était pas idiot de tout réécrire de zéro ?
                  • [^] # Re: Et ça fait quelle taille dans les pages à charger?

                    Posté par  . Évalué à 0.

                    Non, puisque, à en croire les développeurs, la partie bureau/taskbar en était arrivé à un état difficilement maintenable et encore plus à faire évoluer.
                    Ça a pris (et prend encore) du temps pour atteindre un niveau de fonctionnalités équivalent mais ça permettra d'aller beaucoup plus loin dans l'avenir.
  • # Firefox 3.6

    Posté par  . Évalué à 1.

    Un bon test pour Firefox 3.6 (en RC) dont le moteur javascript a été beaucoup amélioré.

    http://hacks.mozilla.org/2010/01/javascript-speedups-in-fire(...)
    • [^] # Re: Firefox 3.6

      Posté par  . Évalué à -5.

      Alors je ne te parle pas des dernières versions de Google Chrome, de Safari et même d'Opéra ;-)
  • # Plantage

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Chez moi les démos plantent 1 coup sur 2 sur un build récent de Chromium...
  • # Intéressant...

    Posté par  . Évalué à 2.

    ...bien qu'actuellement incapable de remplacer quoi que ce soit. L'approche peut sembler folle, mais si on y réfléchit, il y a quoi dans un .swf? Du (presque?) Javascript? Des définitions vectorielles de trucs et de machins?

    Je veux bien que la VM ActionScript soit largement plus performante que les BiduleMonkey et autres V8-injection-directe actuels, mais ça fait une porte de sortie honorable.

    Demain (bon ok, après-demain), on peut faire du contenu Flash un citoyen de premier ordre dans le monde du web. Et peu-être qu'à partir de là, les gens se rendront compte qu'on peut faire de jolies choses sans, l'intégration en mieux.
    • [^] # Re: Intéressant...

      Posté par  . Évalué à 1.

      il y a quoi dans un .swf? Du (presque?) Javascript?
      comme tu dis, du presque javascript sous forme de bytecode pour la vm flash.

      Certain truc js ne sont font pas en as3.
      Genre toto.maFunction = function(){Alert.show("hello world")} qui me semble t il est valide en js mais pas en as (tout du moins pas sans declarer l'objet dynamique).
      Ca doit pouvoir se contourner, vu que c'est compile de toutes facons, et que js est plus large qu'as, donc ca pose pas de pb.

      Ensuite, t'as les ressources (son, video, images, vectorielle ou pas, fontes, bref un gros paquet de trucs). Apparement, il arrive a les lire.

      Et pour finir, t'as les trucs rigolos, genre les liens vers playerglobal.swf, framework.3.4.0.swf, datavizualisation.swf et tout ce genre de machin, dont pas mal font reference a des fonctions natives implementee par la VM flash.
      Bref, tout ca pour dire: chapeau pour la demo technologique, mais revez pas trop, je doute que ca fasse tourner n'importe quel swf un jour.

      Pour les perfs de la vm action script, je mettrais pas ma main a coupe qu'elle est particulierement plus rapide que les macaques et autre jus de legumes a la mode, mais elle a a un gros pb, c'est qu'elle est single threadee, et ca, ca fait tres chier parfois.
      Ou plus precisement: flash ne permet pas de creer un thread pour faire un calcul lourd en arriere plan sans completement geler l'ui le temps que le calcul se finisse. Ca, c'est lourd.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.