Firefox 4 et pilotes de cartes graphiques sous Linux

Posté par (page perso) . Modéré par patrick_g.
Tags : aucun
31
19
jan.
2011
Mozilla
Cette dépêche est tirée du journal de bjacob.

Je m'essaye à l'exercice de la publication LinuxFr pour apporter quelques explications sur le statut de l'accélération graphique dans Firefox 4 sous Linux (plus généralement X11). Je suis le type qui a fait la modification restreignant OpenGL au seul pilote NVIDIA propriétaire dans Firefox 4 sous Linux, donc si vous n'êtes pas contents, c'est moi qu'il faut gronder.

Si vous êtes pressés, je vous conseille de lire au moins ce mail que j'ai envoyé à la liste mesa-dev.

Le fait est qu'on a plein de plantages dans tous les pilotes OpenGL, sauf avec le driver proprio NVIDIA. Donc j'ai restreint OpenGL à ce seul pilote, et j'ai écrit (lien ci-dessus) a mesa-dev pour leur expliquer la situation et leur montrer comment reproduire les problèmes, ce qu'ils ont pu faire très vite, et ils ont fait des rapports de bugs, cf. ce fil de discussion.

Donc les choses avancent : on a une batterie de tests officielle pour WebGL qui permet de valider tranquillement les pilotes et, bien entendu, dès qu'un pilote sera validé, on se dépêchera de l'activer pour Firefox 4.
Ça ne sera pas forcément avant la sortie de Firefox 4 : il ne reste pas beaucoup de temps. Mais ça pourra être dans une sortie mineure, et de toute façon on va se mettre à sortir 3 versions "majeures" par an.

Quelques autres précisions maintenant :
  • Vous pouvez débloquer votre pilote en définissant la variable d'environnement MOZ_GLX_IGNORE_BLACKLIST avant de lancer Firefox.
    Voir le mail à mesa-dev ci-dessus si vous voulez exécuter les tests WebGL.
  • L'accélération due à XRender, via Cairo, est toujours présente. Seul OpenGL est bloqué.
    On utilise potentiellement OpenGL pour 2 choses : pour WebGL et pour les 'Layers' (phase de composition des couches d'une page web, ce qui inclut le redimensionnement et les conversions d'espaces de couleurs pour les images et la vidéo).
  • WebGL est activé par défaut, donc dès que votre pilote est débloqué (voir ci-dessus), vous pouvez faire tourner du WebGL. Votre pilote OpenGL sera utilisé pour exécuter WebGL, mais pour que le résultat soit utilisé directement pour l'affichage sans repasser par la mémoire centrale (ce qui permet d'accélérer encore plus), il vous faut les Layers, voir ci-dessous :
  • les Layers, par contre, ne sont pas encore activés par défaut sous Linux, indépendamment des pilotes, parce qu'il y a un bout de code qui reste à écrire pour ne pas perdre le bénéfice de XRender. (En gros, permettre aux pixmaps de rester sur le serveur X sans faire d'aller-retours inutiles). Tant que ça n'est pas fait, activer les layers cause une perte de performance sur certains benchmarks à base de canvas 2D. Par contre, ça accélère déjà très bien la vidéo et WebGL, par exemple. Si vous voulez activer les Layers, allez sur about:config et activez layers.acceleration.force-enabled.

Dès que les bugs graves qui restent à régler dans Firefox 4.0 seront corrigés, je voudrais m'attaquer à activer les layers par défaut sous Linux. Je pense que ça sera dans la version +1 d'ici quelques mois ; puis, à terme, on a aussi des plans pour se débarrasser complètement de XRender et simplement tout faire par OpenGL, ce qui règlerait pas mal de problèmes : c'est ce qui se passe déjà sous Windows, ou l'équivalent de XRender, Direct2D, est une simple bibliothèque logicielle appelant Direct3D 10. On devrait pouvoir faire aussi bien avec OpenGL à la place de Direct3D 10.
  • # à propos

    Posté par . Évalué à 1.

    peut on espérer une amélioration d'OpenGL, des pilotes libre et propriétaires (notamment pilote catalyst) pour corriger ces bugs avec Firefox 4 ?
    ou alors j'ai pas tout suivi et le bug viendrait de Firefox 4 ?
    • [^] # Re: à propos

      Posté par . Évalué à 10.

      Bjacob
      Je crois que c'est une combinaison de plusieurs facteurs.

      Avant WebGL, il n'y avait pas de batterie de tests officielle et publique de la part de Khronos, pour OpenGL et OpenGL ES. Les developpeurs de pilotes pouvaient soit developper la leur (je crois que les devs de Mesa en ont une, 'piglit'), soit payer une licence pour une batterie de tests proprietaires (je crois que Khronos en vend). Avec WebGL, pour la premiere fois on a une batterie de tests complete et libre:
      https://cvs.khronos.org/svn/repos/registry/trunk/public/webg(...)

      Ensuite il faut bien voir que WebGL touche a 99% de l'API OpenGL ES 2.0 (donc disons 90% de OpenGL 2.1) et atteint donc bien plus de bugs dans les implementations que, disons, Compiz ou Kwin qui se contentent probablement de 20% de l'API, ou meme qu'un jeu video qui va utiliser 50% de l'API.

      Enfin, comme WebGL expose 99% de l'API OpenGL ES 2.0 aux scripts sur le web, les bugs dans les pilotes peuvent tres vite se muer en failles de securite. Un simple plantage est considere comme une faille par deni de service si un script peut le causer quand il veut. Du coup, les fabricants de navigateurs, au moins nous et un autre gros, sont en train d'etablie des listes noires / listes blanches de pilotes, ce que les fabricants de jeux video n'eprouvent pas le besoin de faire


      Glisse :
      C'est exactement ce que fait piglit, donc non on a pas attendu webgl pour tester tout plein de cas tordu. Mais oui on est ravi d'avoir une nouvelle suite de test car il y a probablement des tests qu'on avait pas dans notre suite.

      Les drivers open source passe deja plus de 90% de la test suite webgl...


      Bjacob
      On n'est pas les seuls a penser qu'a terme il n'y a pas vraiment besoin d'autre chose que d'OpenGL, c'est par exemple l'opinion de Keith Packard:
      http://lwn.net/Articles/413335/

      Moins on a d'APIs differentes pour parler au materiel, plus les pilotes/implementations sont petits, mieux ils sont testes. Historiquement, XRender a aussi un gros probleme de mauvais pilotes, qui est une des raisons qui rendent parfois Firefox lent sous linux: Chromium arrive parfois a etre bien plus rapide avec un rendu purement logiciel (Skia), ce qui est un comble.
      (...)
      http://lists.freedesktop.org/archives/mesa-dev/2011-January/(...)

      La discussion a montre que (au moins les versions de dev) les pilotes libres etaient tres pres du but, et qu'il n'y avait qu'un probleme de plantages a corriger.
      (...)
      Par defaut sous linux, comme on n'active pas les 'Layers', on ne cree que le strict minimum (avec les Layers actives on en cree effectivement plus).

      La grosse difference que je vois a ce niveau avec Chrome, c'est plutot qu'ils semblent utiliser des PBuffers alors que nous creons un contexte OpenGL invisible (je crois appuye par un pixmap) et faisons tout le rendu dans un FBO.
      (...)
      Je n'ai pas le temps de tout faire (et notre 'equipe' WebGL n'a que 2 personnes contre 4 ou 5 chez Google). J'ai une carte nvidia. Initialement j'ai essaye (fedora 13 en mai 2010) avec le pilote nouveau, mais ca ne marchait vraiment pas bien du tout; je n'ai pas eu le temps de reessayer depuis.
      (...)



      Crev
      Et dans le cas où ça fonctionne sous chrome, pourquoi ne pas reprendre le même principe ?

      Bjacob
      Parce que c'est une assez mauvaise idee. Les FBOs sont tout simplement plus puissants, par exemple ils nous permettent de parler directement a notre systeme de Layers (on verra si Chromium passe aux FBOs lorsqu'ils implementeront la fonctionnalite equivelente...) Ensuite. a chaque fois qu'on parle avec des ingenieurs de ATI et NVIDIA (ils participent a l'elaboration de WebGL), ils nous confirment que les PBuffers sont consideres comme un 'hack' et que leur support futur n'est pas garanti. Et d'ailleurs initialement, on utilisait des PBuffers et ca n'etait pas supporte par certains pilotes libres sous linux (ca a ete corrige il y a 6 mois je crois). Meme si c'est supporte maintenant, ca montre bien que c'est non-standand.


      Glisse

      Un bug c'est parceque le context GL a des valeurs pas normale ymin>ymax (forcement ca peut pas marcher mais oui on devrait pas assert ou segfault dans de tel cas).

      Le second c'est la creation d'un context GL avec un format pas correct, la je vois pas vraiment ce qu'on peut faire de notre cote, c'est juste interdit de cree un context GL avec un format pas supporte c'est a firefox de verifier ca. Apres naturellement le driver a pas a segfault ou abort face a ca.


      Bjacob
      Ce qui tu ecris ici m'interesse beaucoup!

      Peux-tu me pointer plus precisement ou tu vois ca, je voudrais patcher Firefox pour qu'il evite de faire ca.
      • [^] # Re: à propos

        Posté par . Évalué à 10.

        Des éléments manquant à la dépêche, peut être ? Et issus de la discussion, des commentaires du journal à l'origine de la dépêche.

        Espérant que cela apporte un condensé des infos des commentaires du journal d'origine, et un plus à la dépêche. Sinon, moinssez :-)
        • [^] # À ne pas oublier ...

          Posté par (page perso) . Évalué à 4.

          ... encore un élément manquant à la dépêche (faut dire que c'est tout frais): Brian Paul a examiné les crashs et dit que ça serait dû à Firefox, qui utilise une extension sans vérifier qu'elle est disponible (GL_ARB_ES2_compatibility) et qui accède aux "uniforms" (genre de constantes pour les shaders) avec des indices invalides.

          Bref, la paille dans l'œil du voisin, tout ça ...
          • [^] # Re: À ne pas oublier ...

            Posté par (page perso) . Évalué à 4.

            Allez, je me fends d'une petite traduction ...
            Brian Paul:
            On dirait que qu'un grand nombre de plantages apparaissent parceque WebGL suppose que le driver OpenGL implémente GL_ARB_ES2_compatibility alors que cette extension n'est en fait pas présente. Mesa génère une erreur et le test plante.

            Par exemple, WebGL appelle glGetIntegerv(GL_MAX_FRAGMENT_UNIFORM_VECTORS) et Mesa génère GL_INVALID_ENUM. Le test gl-get-calls est marqué comme échec.

            Si GL_ARB_ES2_compatibility est obligatoire pour WebGL, il devrait y avoir une vérification. Savez-vous ce qui se passe dans ce cas ?

            Je n'ai pas creusé beaucoup des échecs, mais beaucoup d'erreurs GL sont générées par Mesa à causes d'indices invalides lors de l'accès aux uniforms de GLSL, etc. Ça aussi me semble suspicieux.

            Eric Anholt a commencé à ajouter le support de GL_ARB_ES2_compatibility dans Mesa mais il n'est pas activé dans beaucoup de drivers pour l'instant. Je pourrais travailler à l'activer pour les drivers swrast et gallium.
            • [^] # Re: À ne pas oublier ...

              Posté par (page perso) . Évalué à 5.

              non, Brian dit "failures" ce qui veut dire "echecs" (des tests), pas plantages.

              Bref, il y a en effet un truc a corriger a ce niveau dans Firefox, mais ca n'a rien a voir avec les plantages.

              Pour les plantages, les devs de xorg ont bien confirme que c'etaient des bugs de leur cote, mais en meme temps Glisse m'a pointe vers des trucs que Firefox pourrait (et devrait) faire pour eviter de les declencher: je regarde.
              • [^] # Re: À ne pas oublier ...

                Posté par (page perso) . Évalué à 1.

                Oui désolé, j'avais mis "plantage" pour "failure" partout, puis j'ai mis "échec" à la place mais j'en ai laissé passer, et on ne peut plus modifier après avoir posté ...
                • [^] # Re: À ne pas oublier ...

                  Posté par . Évalué à 0.

                  Fais gaffe tout de meme tes posts precedents allez declencher une guerre entre deux projets du libre. Dois t'on te rappeler comment sont succeptibles les devs? :)

                  En tout cas Benoit Jacob semble etre plus pose que certains de la liste du kernel meme si cela manque de piquant du coup on peut apprecier aussi! :)
                  • [^] # Re: À ne pas oublier ...

                    Posté par . Évalué à 1.

                    Google translate ?

                    BeOS le faisait il y a 15 ans !

                  • [^] # Re: À ne pas oublier ...

                    Posté par (page perso) . Évalué à -3.

                    Ouais, ce qui m'a gêné c'est que si tu regardes son post initial, en gros tout est de la faute des drivers sous linux. Au final tu vois que les torts sont partagés, mais Xorg n'a pas la puissance de feu médiatique de Mozilla, donc le mal est fait.
                    • [^] # Re: À ne pas oublier ...

                      Posté par . Évalué à 8.

                      Tu sais lorsque tu bosses sur un projet au bout d'un moment il devient tres difficile d'etre critique d'ou l'importance des reviewers externes et de discussion.

                      D'apres ce qui se dit ici et ailleurs les torts sont partages dans le sens ou il y avait des bugs dans les des deux projets et si l'on regarde du bon cote c'est que cela a mis un coup de pied dans la fourmilleres et la prochaine version de drivers Mesa va etre de tres bonne facture avec de moins en moins de bugs et de manques.

                      De plus il a poste sur la mail liste mesa-dev, il n'est pas passe par un communique de presse disant que c'etait de la merde etc. Au contraire son post a ete plus que constructif je trouve. Certes il met la faute sur mesa mais il a aussi admit que son code avait des problemes et ne faisait pas les choses a 100% comme il faudrait et il tente de corriger et ca c'est le principal.
                    • [^] # Re: À ne pas oublier ...

                      Posté par . Évalué à 3.

                      Ouch personne chez XOrg ne peux poster un journal ici ?
                      Linuxfr est devenu tellement une référence que chaque journal peut déclencher la mort ou la résurrection d'un projet ?

                      Faut pas préter trop d'attention à un journal, hein. J'ai l'impression de revoir ceux qui postaient un journal pour dire qu'ils étaient pas contents d'avoir étaient moinisé dans un commentaire.

                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                    • [^] # Re: À ne pas oublier ...

                      Posté par (page perso) . Évalué à 10.

                      Ouais, ce qui m'a gêné c'est que si tu regardes son post initial, en gros tout est de la faute des drivers sous linux.

                      Ben, les plantages sont bel et bien des plantages des drivers, ensuite on pourrait et devrait valider mieux les parametres avant de faire nos appels, ce qui peut eviter certains plantages, ca oui, mais il reste que les drivers ne sont jamais censes planter.

                      Au final tu vois que les torts sont partagés, mais Xorg n'a pas la puissance de feu médiatique de Mozilla, donc le mal est fait.

                      Tu rigoles ou quoi? Puissance de feu? Un journal linuxfr, tu appelles ca de la puissance de feu? Et tu ne crois pas que les devs de xorg peuvent aussi faire des journaux linuxfr si ca leur chante?

                      Faut arreter de chercher du conflit la ou il n'y en a pas. Entre les devs de xorg qui reglent leur plantages et nous qui reglons notre manque de validation qui apparament conduit a declencher ces plantages, tout ca devrait bientot etre du passe.
                      • [^] # Re: À ne pas oublier ...

                        Posté par (page perso) . Évalué à -10.

                        Et l'ouverture d'un fichier n'échoue jamais. Et il y a toujours de l'espace disque disponible. Il y a toujours de la mémoire disponible. Pourquoi s'embêter à tester le retour d'erreur des fonctions appelées ?
                        • [^] # Re: À ne pas oublier ...

                          Posté par . Évalué à 10.

                          Et toi quand tu programmes tu ne prens jamais de raccourcis? On peut avoir des exemples de code de ta part dans un projet majeur du libre?

                          Cela sert a quoi ce genre d'attaque gratuite? A degoutter un developpeur?

                          Ca va arreter ce genre de truc? Les deux cotes ont travaille ensemble et dans la grande tradition du libre tout a ete fait a visage decouvert. Il n'y a rien de cache et aucune des deux partis concernes n'a commence a insulter l'autre. Pourquoi est-ce que des personnes non directement implique se permette de faire ce genre de remarque? Cela me depasse!
                          • [^] # Re: À ne pas oublier ...

                            Posté par (page perso) . Évalué à 7.

                            Première fois depuis le 30 septembre 2009, date de création de ton multi que je suis d'accord avec toi.

                            Ca méritait un commentaire.
                            • [^] # Re: À ne pas oublier ...

                              Posté par . Évalué à 6.

                              il a du se planter de compte pour poster ^^

                              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                          • [^] # Re: À ne pas oublier ...

                            Posté par (page perso) . Évalué à -7.

                            Dans les prototypes je prends des raccourcis. Et encore, ce n'est pas toujours une bonne idée, parce qu'on perd souvent plus de temps à chercher des erreurs à la con, alors qu'on aurait eu le message d'erreur immédiatement si on avait gérer l'erreur au bon endroit.

                            Ceci dit, je ne vois pas pourquoi tu t'emportes sur mon commentaire. Ce que je relevais, c'est la phrase « il reste que les drivers ne sont jamais censes planter ». C'est bien ça qui me pourri quotidiennement la vie. Avec des développeurs, collègues ou non, qui suppose que ça ne vaut pas le coup de se casser la tête à vérifier le retour des fonctions. C'est un peu pour contrer ce genre de comportement qu'on a d'ailleurs inventer les exceptions, histoire que ce ne soit pas aussi facilement ignoré.

                            Personnellement, je préfère dégoûter un souillon plutôt que de le soutenir dans l'erreur. On a assez de code sale, impossible à maintenir et a fortiori bourré de faille de sécurité pour se payer le luxe de soutenir ceux qui en rajoute.

                            Systématiquement, quand j'utilises une fonction qui peut générer des erreurs, je les gère.
                            • [^] # Re: À ne pas oublier ...

                              Posté par (page perso) . Évalué à 8.

                              vec des développeurs, collègues ou non, qui suppose que ça ne vaut pas le coup de se casser la tête à vérifier le retour des fonctions.

                              Ça ne doit impacter que le code que tu écris, si le code que tu utilise fait tout planter parce que tu ne vérifie pas un retour de fonction, c'est qu'il y a un problème dans le code.

                              Pour reprendre ton exemple avec les ouvertures de fichiers, ce n'est pas parce que tu ne vérifie pas les retour qu'il va y avoir un kernel panic.

                              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                              • [^] # Re: À ne pas oublier ...

                                Posté par (page perso) . Évalué à -2.

                                Planter dans quel sens ?

                                Lorsqu'en C une fonction segfault, je considère d'abord que c'est de ma faute. Parce qu'en C il est parfois difficile d'utiliser une fonction correctement. Du genre, fournir une zone mémoire non-allouée ou non-initialisée. Un segfault dans ces cas-là est évidement salutaire (c'est toujours pire un programme qui tombe en marche), et quelque soit la localisation du segfault. Si memmove plante, je ne vais pas râler contre UNIX/POSIX.
                                En l'espèce, dans le présent thread, on parlait des fonctions OpenGL qui échouaient, et que le développeur a ignoré de vérifier le retour. Les crash du serveur X (ou d'un module noyau s'il y a) n'étaient pas considérés. Il est évident que l'utilisateur des fonctions ne peut rien faire si elles partent totelement en couille, malgré la rigueur du développeur.

                                Je ne peux constater qu'avec effrois que l'époque où les contributeurs aimaient la qualité et la rigueur, avaient une exigence en regard des logiciels propriétaires, est belle et bien révolue sur DLFP. Toute critique franche d'une pratique misérable (la programmation à la truelle, en l'occurrence) est violemment réprimée par la masse. C'est déplorable.
                                • [^] # Re: À ne pas oublier ...

                                  Posté par . Évalué à 4.

                                  Toute critique franche d'une pratique misérable (la programmation à la truelle, en l'occurrence) est violemment réprimée par la masse. C'est déplorable.

                                  Quand cela arrive apres la bataille et que cela n'amene a rien si ce n'est a probablement degoutte le dev. Mais c'est beau quelqu'un qui programme sans jamais avoir de bug. C'est vrai c'est beau. (Au passage le code tournait avec certains drivers mais pas avec d'autre donc mettre en cause un probleme de driver etait assez logique comme d'ailleurs l'a montre l'echange avec les devs mesa meme si certaines choses auraient du etre mieux gere).
                                  • [^] # Re: À ne pas oublier ...

                                    Posté par (page perso) . Évalué à 1.

                                    Je n'ai pas dit que je n'ai jamais de bogue. D'ailleurs, statistiquement, il y a toujours de bogues.

                                    Quand on arrive après la bataille, on compte les morts, on tire les leçons des erreurs commises. C'est un travail important, qui est souvent négligé.

                                    Au passage le code tournait avec certains drivers

                                    Ce code compile et « tourne » :
                                    #include <string.h>
                                    int main()
                                    {
                                    char * orig = "toto", dest ;
                                    strcpy(&dest, orig) ;
                                    }

                                    Bon d'accord, cet exemple n'est pas du même tonneau. Mais imagines-tu faire un *scanf, un write, un read, un open, etc sans vérifier qu'ils ont bien retourné une valeur attendue ? Non, évidement que non. Parce que les développeurs qui ont un peu de bouteille savent que ne pas contrôler le résultat d'une fonction, c'est s'assurer une consommation excessive de paracétamol dans un futur plus ou moins proche.

                                    Et c'est uniquement cela que je critiquais.
                                • [^] # Re: À ne pas oublier ...

                                  Posté par (page perso) . Évalué à 9.

                                  Toute critique franche d'une pratique misérable (la programmation à la truelle, en l'occurrence) est violemment réprimée par la masse

                                  Non ce qui est réprimé c'est le donnage de leçons depuis ton mini-piedestal , leçons que tout le monde connait déjà. Ca ne sert à rien à part à te défouler et à etre désagréable avec l'auteur du journal. Un minimum de respect et de bienveillance ne fait pas de mal. Si tu veux aborder le pb de la non verification des codes d'erreurs en général, fais le dans ton propre journal, mais pas ici en rebondissant sur un quart de phrase alors que tu ne connais pas le contexte, tu ne connais pas le code, et tu ne connais la personne à qui tu adresses ton iritation.

                                  Ce thread est lourd, et je suis lourd d'en remettre une couche, je sais.
                                  • [^] # Re: À ne pas oublier ...

                                    Posté par (page perso) . Évalué à -1.

                                    Je n'ai manqué de respect à personne, j'ai émis une critique acerbe sur un point qui me hérisse le poil.

                                    Je ne lis jamais les journaux publiés sur DLFP. Pourquoi en ferais-je un moi-même. Je préfère venir débattre plutôt que de râler dans mon petit coin (sur mon petit piédestal).

                                    Je ne connais effectivement pas ce point précis du code, ça fait un moment que je n'ai pas fouiné dans Gecko.

                                    Je m'en fous de connaître ou non la personne avec qui je discute. Ce qui m'intéresse c'est la discussion, le débat (voir le troll), les arguments échangés. Pour l'instant je m'en prends plein la gueule parce que je déplore un état de fait.

                                    De plus, j'en veux bien plus à ceux qui m'encensent qu'à ceux qui me critiquent ouvertement. Ces derniers me font avancer, évoluer, plutôt que de croupir dans la médiocrité.
                                    • [^] # Re: À ne pas oublier ...

                                      Posté par . Évalué à 2.

                                      Ça en fait des principes....
                                      Comme quoi c'est beau internet, cet univers à la tron où chaque individus à plus de morale que la plupart des prix nobels.

                                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                        • [^] # Re: À ne pas oublier ...

                          Posté par . Évalué à 9.

                          Comment fais-tu pour tester le retour d'erreur d'une fonction qui a planté ?
                      • [^] # Re: À ne pas oublier ...

                        Posté par (page perso) . Évalué à -5.

                        Sans vouloir du tout rentrer dans le style des autres réponses, je suis toujours surpris de ce genre de déclaration :

                        > on pourrait et devrait valider mieux les parametres avant de faire nos appels, ce qui peut eviter certains plantages, ca oui, mais il reste que les drivers ne sont jamais censes planter

                        En gros on ne vérifie pas suffisamment notre code, et donc ça fait planter. Nous on le fait mais eux ils ne devraient pas, parce que c'est des drivers, toussa.
                        Je comprend bien que les drivers sont beaucoup plus critiques que firefox, mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même.

                        Maintenant, ce qui est plutôt une très bonne nouvelle (au delas de tout le blabla inhérent dont il faut finalement assez peu ce soucier ;) ) :
                        > tout ca devrait bientot etre du passe
                        • [^] # Re: À ne pas oublier ...

                          Posté par . Évalué à 5.

                          mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même.

                          La difference, c'est que d'un cote on a une application, qui tourne en espace utilisateur et qui si elle plante n'affecte qu'elle meme.

                          Lorsque ton serveur X plante, voir la machine entiere se vautre, ca a un peu plus de consequences pour l'utilisateur. Et comme c'est les couches basses du systeme, elles sont sensees dans une certaine mesure resister aux applications mal ecrites et qui font n'importe quoi.
                          • [^] # Re: À ne pas oublier ...

                            Posté par . Évalué à -2.

                            Ben en même temps, le driver plante rarement tout seul. S'il plante, c'est par rapport à ce qu'une application en user-land lui a demandé. Sinon, tout ça ne sert à rien.

                            Donc les deux sont aussi critiques l'un que l'autre.

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

                            • [^] # Re: À ne pas oublier ...

                              Posté par . Évalué à 2.

                              Le conseil d'un prof de DUT à propos des styles de vérification du code :
                              * dans ton propre code : tu peux te permettre de donner les préconditions et supposer que tu les respecteras lors de l'appel
                              * si tu distribues ton codes : tu blindes les APIS et vérifies systématiquement que les préconditions sont respectées après les appels de fonctions.
                              • [^] # Re: À ne pas oublier ...

                                Posté par . Évalué à 2.

                                Dans le 2ième point, tu peux même le faire en assertion pour éviter trop de lourdeur dans le code release.

                                "La première sécurité est la liberté"

                          • [^] # Re: À ne pas oublier ...

                            Posté par (page perso) . Évalué à 9.

                            J'ai pas dit que le serveur X plantait, hein. Je parle de la partie du driver qui est sous forme de bibliotheque appelee indirectement par l'application, via GLX. Seul Firefox plante.

                            Pourtant, il reste que toute bibliotheque qu'une application appelle a un 'contrat' avec l'application qui definit bien clairement a qui la faute, en cas de plantage. Et la fonction glxMakeCurrent() de GLX n'est pas censee planter. Or c'est ce qui se passe avec certain drivers dans certaines circonstances rencontrees par Firefox.

                            Bref, encore un commentaire aggressif pour rien de la part de CrEv, merci bien (j'ai ma dose).
                            • [^] # Re: À ne pas oublier ...

                              Posté par . Évalué à 4.

                              Bref, encore un commentaire aggressif pour rien de la part de CrEv, merci bien (j'ai ma dose).

                              Au vu des notes respectives de vos messages, je pense pouvoir dire que beaucoup de monde te soutient.
                              En un mot : merci !

                              ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

                            • [^] # Re: À ne pas oublier ...

                              Posté par (page perso) . Évalué à 1.

                              > de la part de CrEv
                              hum, j'adore lorsqu'on rentre sur le domaine perso, c'est tellement mieux
                              Pour reprendre le début de ton journal "Je m'essaye à l'exercice du journal LinuxFr" il reste encore la partie style / susceptibilité à appréhender alors

                              Dans tous les cas je pense que tu as très mal pris mon message alors qu'il était en aucun cas méchant et encore moins personnel.
                              Mais bon, on peut toujours faire une petite explication de texte.
                              Tout d'abord :
                              "Sans vouloir du tout rentrer dans le style des autres réponses" -> ben oui, je trouvais que d'autres réponses partaient en vrille alors je voulais faire soft pour le coup...
                              "Je comprend bien que les drivers sont beaucoup plus critiques que firefox" -> donc vous pouvez tous répondre que userland, drivers, toussa ... mais je l'ai déjà écris...
                              "mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même." -> ben oui, désolé mais lorsqu'on lit [https://linuxfr.org/comments/1201200.html#1201200] :
                              "ça serait dû à Firefox, qui utilise une extension sans vérifier qu'elle est disponible (GL_ARB_ES2_compatibility) et qui accède aux "uniforms" avec des indices invalides." il y a bien faute côté mozilla. Evidemment les drivers ne devraient pas planter et faire des vérifs, mais ce genre de vérif (vérifier que la fonctionnalité est dispo) reste à faire du côté mozilla. Si le drivers devrait être capable de le gérer, mozilla ne devrait lui pas le faire non plus. Le bon côté est que cela permet par contre de corriger des bugs potentiels liés à une mauvaise utilisation.
                              D'ailleurs je ne faisais que reprendre tes propos : "on pourrait et devrait valider mieux les parametres avant de faire nos appels"

                              "il reste que toute bibliotheque qu'une application appelle a un 'contrat' avec l'application qui definit bien clairement a qui la faute"
                              et on rajoutera dans les règles [https://linuxfr.org/comments/1201485.html#1201485]
                              Le conseil d'un prof de DUT à propos des styles de vérification du code :
                              * dans ton propre code : tu peux te permettre de donner les préconditions et supposer que tu les respecteras lors de l'appel
                              * si tu distribues ton codes : tu blindes les APIS et vérifies systématiquement que les préconditions sont respectées après les appels de fonctions.
                              * de toute bibliothèque externe tu te méfiera, tu ne sais pas si le boulot est bien fait (en gros) et tes appels tu blindera (surtout si tu passes kernel-land et que ça risque d’entraîner ton soft avec)


                              Et en plus, histoire que mon message initial ne soit pas mal interprété, je finissais par :

                              Maintenant, ce qui est plutôt une très bonne nouvelle (au delas de tout le blabla inhérent dont il faut finalement assez peu ce soucier ;) ) :
                              > tout ca devrait bientot etre du passe


                              Mais pour finir cette fois :
                              > Bref, encore un commentaire aggressif pour rien de la part de CrEv, merci bien (j'ai ma dose).
                              (ok, je devrais pas écrire la suite je vais encore probablement me faire moinser...)
                              Il était évident qu'en venant raconter ton histoire elle allait se faire décortiquer de tous les côtés. Et je pense que c'est bien (je ne voudrais justement pas te dissuader de recommencer car on a appris pas mal de choses). Nombre de commentaires (avec des styles peut-être plus ou moins direct - oui je parle juste de direct plutôt que d’agressif car en aucun cas ce n'était des attaques de ma part) ont permit de préciser exactement la nature des problèmes, en mettant en évidence des tords partagés même si certains ont plus de responsabilité que d'autre quant à l'issue du problème (en l’occurrence les drivers).
                              • [^] # Re: À ne pas oublier ...

                                Posté par . Évalué à 2.

                                http://lists.freedesktop.org/archives/mesa-dev/2011-January/(...)

                                Qui montre qu'il y a aussi des problemes cote drivers!
                                • [^] # Re: À ne pas oublier ...

                                  Posté par (page perso) . Évalué à 2.

                                  merci d'appuyer sur le aussi alors que j'en parle déjà (qui a dit dialogue de sourd ?) :
                                  * tords partagés même si certains ont plus de responsabilité que d'autre quant à l'issue du problème (en l’occurrence les drivers)
                                  * le driver devrait le gérer

                                  mais par contre merci d'avoir replacé ce lien
                              • [^] # Re: À ne pas oublier ...

                                Posté par . Évalué à 2.

                                ( + 1 sur ce thread long et lourd)

                                + 1 sur le fait que la formulation était peut être maladroite (cela a touché Bjacob, donc c'était maladroit)
                                + 1 sur le fait que tes questions, Crev, (me) semblaient pertinentes


                                + 1 sur le fait que je fais parfois pareil, et que j'ai vu de nombreuses autres personnes faire et dire bien pire, sur irc

                                Perso je l'ai lu comme : questions pertinentes, et affirmation demandant en fait aussi une réponse. Bref le coup classique du "dans la vie réelle tu aurais vu mon sourire et mes yeux brillés, éléments indispensables à la compréhension du ton de la phrase. Ouhai mais on est pas dans la vie réelle..."

                                amlt
                        • [^] # Re: À ne pas oublier ...

                          Posté par . Évalué à 3.

                          Je comprend bien que les drivers sont beaucoup plus critiques que firefox, mais la logique voudrait qu'on ne reproche pas aux autres ce qu'on applique pas nous même.

                          C'est une attaque gratuite. Je suis sûr que si tu rapportes un plantage de Firefox sur une entrée incorrecte (javascript foireux par exemple), ils vont essayer de le corriger.
                          • [^] # Re: À ne pas oublier ...

                            Posté par (page perso) . Évalué à 2.

                            Comme déjà indiqué, non ce n'est pas une attaque. Comme l'a dit tankey un poil plus haut je pense qu'on entre essentiellement dans un problème de formulation (qui est surement de mon fait)
                            Mais oui, la logique voudrait que lorsqu'on demande à une partie externe d'être irréprochable, c'est pas pour de l'autre côté ne pas faire toutes les vérifs qui s'imposent. Ca reste à mon sens assez logique.
                            Mais bon, là on arrive quand même dans du bel enculage de drosophile avec multi répétition / justification des mêmes contenu...

                            > Je suis sûr que si tu rapportes un plantage ...
                            Aucun rapport.

                            Ha ok, je commence à comprendre ... en fait vous (je reste bien général) l'avez tous pris comme une attaque contre le (les ?) dev de firefox ... ce que ce n'était pas. Lorsque je parle de logique, je parle de logique de dev, absolument pas de la faute de quelqu'un en particulier.

                            /franchement ça me gave que tout soit toujours pris de manière perso, surtout qu'on aurait pu parler des problèmes, de pourquoi mozilla ne faisait pas les tests (il y a surement une bonne raison, même si c'est jusque que les drivers utilisés n'en avaient pas besoin), pourquoi c'était pas blindé côté driver, pourquoi on s'en aperçoit si tard, etc

                            /me doit se trouver des disclaimer pour les prochains posts techniques...
                            • [^] # Re: À ne pas oublier ...

                              Posté par . Évalué à 2.

                              Mais oui, la logique voudrait que lorsqu'on demande à une partie externe d'être irréprochable, c'est pas pour de l'autre côté ne pas faire toutes les vérifs qui s'imposent.

                              Mais non, justement, ça n'est pas la même chose. Tu compares le fonctionnement d'une fonction d'API disponible pour d'autres programmes (les drivers) avec le fonctionnement interne d'un programme (Firefox) qui prend parfois des raccourcis. Oui, prendre des raccourcis c'est pas bien, mais c'est largement pire quand ça entraîne potentiellement le crash d'un programme tiers qui a oublié de valider les paramètres qu'il envoie à une API.

                              Donc tu n'as pas compris mon analogie, parce que l'équivalent côté Firefox de ce bug de drivers, c'est si un bout de code javascript ou HTML donné (par exemple un truc à la syntaxe incorrecte) permettait de crasher Firefox au lieu d'avoir simplement un joli message d'erreur. Et c'est là que je dis qu'à mon avis ils seront prompts à corriger ce genre de problème.

                              pourquoi mozilla ne faisait pas les tests (il y a surement une bonne raison, même si c'est jusque que les drivers utilisés n'en avaient pas besoin

                              La bonne raison dans ces cas-là c'est quasiment toujours la paresse (et l'utilisation d'un langage bas niveau sans système d'exceptions :-)).
                              • [^] # Re: À ne pas oublier ...

                                Posté par (page perso) . Évalué à 1.

                                ok, oui en effet je n'avais pas bien saisi ton analogie.

                                > La bonne raison dans ces cas-là c'est quasiment toujours la paresse
                                ha ben voilà, on y arrive ! (en fait je pensais qu'on y serait arrivé beaucoup plus tôt)
                                Pour reprendre ce que disais tankey, mes affirmations (maladroites) visaient surtout à ce qu'on réponde quelque chose du genre (ou tout autre justification qu'elle qu'elle soit)...

                                /disclaimer : je sais bien que l'affirmation d'Antoine n'est pas relative à firefox, pas la peine de croire que je prend ça comme une réponse sur le problème de firefox /disclaimer

                                Et oui, si on ne fait pas ses propres vérifs par paresse, on ne peut absolument pas exiger que d'autres fassent les leurs !
                                • [^] # Re: À ne pas oublier ...

                                  Posté par . Évalué à 3.

                                  > La bonne raison dans ces cas-là c'est quasiment toujours la paresse
                                  ha ben voilà, on y arrive ! (en fait je pensais qu'on y serait arrivé beaucoup plus tôt)


                                  Et le probleme du temps cela ne vous traverse pas l'esprit aussi? Il n'y a que 24h dans une journee et surement beaucoup moins pour programmer et parfois d'autre imperatif dans la vie qui contrairement a un logiciel ne peuvent pas attendre (les momes par exemples).
                                  • [^] # Re: À ne pas oublier ...

                                    Posté par (page perso) . Évalué à 8.

                                    Sans oublier le temps passé à lire puis à répondre sur LinuxFR :-)
                                  • [^] # Re: À ne pas oublier ...

                                    Posté par (page perso) . Évalué à 2.

                                    ben dit donc, je dois soit vraiment mal m'exprimer, soit c'est toujours interprété comme souhaité et non comme écrit...

                                    le "on y arrive" fait référence à n'importe qu'elle raison qui pourrait être donné, et non uniquement "la paresse". D'ailleurs il y avait un zoli disclaimer qui précisais bien que je ne prenais pas ça comme une réponse pour firefox bla bla bla
                                    Donc oui, le temps peut être une raison, la paresse aussi, être mauvais aussi, etc. Il peut y avoir plein de raison, mais j'aurais bien voulu connaître la vrai ...
                                    • [^] # Re: À ne pas oublier ...

                                      Posté par . Évalué à 3.

                                      Donc oui, le temps peut être une raison, la paresse aussi, être mauvais aussi, etc. Il peut y avoir plein de raison, mais j'aurais bien voulu connaître la vrai ...

                                      La paresse ca veut dire rien foutre et c'est legerement pas tres sympa et honnetement cela sert a quoi de savoir qu'il a proscraniser pendant 2 mois ou que la veille du jour ou il da ecrit ce bout de code, il a passe une nuit blanche parceque son mome etait malade ou 1000 autres raisons. Le logiciel a ete corrige avant sa sortie et donc les differentes beta et RC servent a quelque chose. On parle d'une version de developpement je te rappelle.
                      • [^] # Re: À ne pas oublier ...

                        Posté par (page perso) . Évalué à 1.

                        Oulala, ça dégénère dans le coin. Désolé, je ne pensais vraiment pas troller.


                        Tu rigoles ou quoi? Puissance de feu? Un journal linuxfr, tu appelles ca de la puissance de feu? Et tu ne crois pas que les devs de xorg peuvent aussi faire des journaux linuxfr si ca leur chante?


                        Non non, je parlais plutôt du foin sur Slashdot & co. Effectivement, Linuxfr c'est bien mais .. heuu .. un peu moins visible peut-être ?
                        • [^] # Re: À ne pas oublier ...

                          Posté par (page perso) . Évalué à 5.

                          Mais non, attends! Le foin sur Slashdot et compagnie, ce n'est pas nous qui l'avons cause!

                          Ces sites ont tous repris en echo une phrase effectivement ecrite par un developeur de Mozilla (Boris) mais qu'il avait ecrite en commentaire sur une entree de blog:

                          https://hacks.mozilla.org/2011/01/firefox-4-beta-9-a-huge-pi(...)

                          Il n'avait donc absolument pas l'idee que ca serait repercute avec un tel echo.
                          • [^] # Re: À ne pas oublier ...

                            Posté par . Évalué à 3.

                            On va etre honnete sur le coup c'est un avantage du "closed source" tu peux faire plein de truc sale, tu peux programmer comme un porc mais comme personne ne voit le code c'est pas grave et tu peux faire reporter le probleme sur les drivers ou l'interface chaise clavier (ce que fait de facon systematique Microsoft vous remarquerait).

                            Enfin good luck et t'inquiete pas nous sommes beaucoup a apprecier les explications du problemes et les efforts mis derriere pour le resoudre.
    • [^] # Re: à propos

      Posté par . Évalué à 2.

      Pour les drivers intel cela semble bon (au moins en ce qui concerne les crashs):

      http://linuxfr.org/comments/1201078.html#1201078

      Pour les drivers Catalyst il faut poser la question a AMD ce sont les seuls qui puissent y repondre (bon courage...). Pour les drivers libres ATI un des personnes en charges est deja en train de regarder (et de trouver) les problemes (articles phoronix).

      Donc pour repondre a ta question: Pour les drivers libres tous les espoirs sont permis pour les autres on peut juste faire une reponse de normand.
      • [^] # Re: à propos

        Posté par . Évalué à 1.

        Mais si jamais la situation ne s'améliore pas avec ATI, que va-t-il se passer ?
        Mozilla n'activera jamais par défaut WebGL sur les machines équipées d'une ATI ?
        • [^] # Re: à propos

          Posté par . Évalué à 2.

          Les drivers proprios on ne peut rien faire juste attendre que AMD se decident a regler (ou non) le probleme. L'autre solution serait que AMD sponsorise des machines pour les projets tel que firefox comme ca les devs developperaient peut etre plus en fonction des drivers catalysts? Perso je ne pense pas que cela soit une bonne solution et je prefere utiliser des drivers opensource peut etre moins perfermants mais au moins stable et integre au noyau d'ou une mise en veille et une hibernation parfaite.
          • [^] # Re: à propos

            Posté par . Évalué à 3.

            Le pilote de ma carte ATI est bel et bien libre et intégré dans le noyau, mais malheureusement la mise en veille et l'hibernation ne marchaient fort pas la dernière fois que j'ai essayé.
        • [^] # Re: à propos

          Posté par . Évalué à 2.

          Il y aussi la possibilité d'utiliser un rendu OpenGL software non?
          Bien sûr ça mettrait à genoux la machine, mais bon c'est mieux que rien..
        • [^] # Re: à propos

          Posté par (page perso) . Évalué à 1.

          Mozilla n'activera jamais par défaut WebGL sur les machines utilisant Catalyst.
          Par contre, pour les machines utilisant les drivers libres radeon ou radeonhd, c'est une autre histoire…
          • [^] # Re: à propos

            Posté par . Évalué à 2.

            Pourquoi pour Catalyst? Si Catalyst passe les tests il n'y a pas plus de raison de le refuser qu'il y en a d'accepeter Nvidia.
            • [^] # Re: à propos

              Posté par (page perso) . Évalué à 4.

              Oui, bien sur!
              Je ne sais pas pourquoi Asgeir a dit "jamais".
              Les devs du pilote ATI proprio ont meme repondu dans mon fil de discussion sur mesa-dev.
              • [^] # Re: à propos

                Posté par . Évalué à 3.

                Franchement, on va t'apprendre un truc , de la part des ATIstes qui utilisent régulièrement Linux ( et qui codent pas sous OpenCL/ sont pas sous contrata dans des grosses boites américaines/... ) à tous les NVidiaistes :


                OSEF des Catalysts . On est pas sous Windows !


                On veut des drivers libres qui continuent de progresser au rythme où ils progressent actuellement.

                Sedullus dux et princeps Lemovicum occiditur

  • # Hmm

    Posté par (page perso) . Évalué à 10.

    J'imagine que ca a déjà du être demandé via "Suivi"...

    Mais ca serait quand même pas mal de pouvoir migrer un journal en dépêche quand ce dernier en vaut le coup, j'en vois deux dernièrement:
    - Ce dernier
    - Le journal sur Xfce

    Cela permettrait de garder les commentaires du journal et de pas avoir à tout répéter dans la news...
    • [^] # Re: Hmm

      Posté par (page perso) . Évalué à 1.

      Les modérateurs et administrateurs peuvent convertir les journaux en dépêche. Tu peux donc le proposer sur : http://linuxfr.org/redacteurs/ par exemple, ou envoyer un message aux modos.

      Je pense qu'une plus grande interaction journaux / dépêches est globalement une bonne idée : n'hésite pas.
      • [^] # Re: Hmm

        Posté par (page perso) . Évalué à 2.

        Tiens, salut toi, ca fait un baille :)

        Effectivement, je ne savais pas, je note ceci dans ma "basket" ;)
      • [^] # Re: Hmm

        Posté par (page perso) . Évalué à 7.

        Les modérateurs et administrateurs peuvent convertir les journaux en dépêche.

        Le hic actuel est qu'on perd tous les commentaires (cf tankey qui doit faire des copier coller du fait que le débat à déjà eu lieu sur un sujet). Et certes il y a des trolls, mais beaucoup de commentaires LinuxFriens ont beaucoup de valeur ajoutée au journal, ne transférer que le journal, sans les commentaires, c'est dommage.
    • [^] # Re: Hmm

      Posté par (page perso) . Évalué à 5.

      Le problème a déjà été débattu et il y a (au moins) deux raisons pour ne pas garder les commentaires: Le contenu n'est pas exactement le même que le journal (il y a eu une correction de certaines erreurs et pas mal de commentaires deviennent obsolète et n'ont rien à faire avec ce nouveau contenu ça fait bizarre. Et puis l'« l'ambiance » des commentaires dans les dépêches ne sont pas les mêmes, ce n'est donc pas forcément pertinent des les faire migrer.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Hmm

        Posté par (page perso) . Évalué à 4.

        Argh j'aurai du lire ce message avant d'écrire mon autre commentaire.
        Effectivement, les arguments contre sont pertinents, cruel dilemme.
        • [^] # Re: Hmm

          Posté par . Évalué à 1.

          Mais les lecteurs des dépêches sont aussi les lecteurs des journaux. Je ne pense pas qu'il y ai beaucoup de gens qui ne regardent *que* les dépêches et qui se refusent à cliquer sur le moindre jourNal...

          Donc pour ceux qui, comme moi, lisent les journaux et les dépêches, on voit double et c'est un peu horripilant de suivre les mêmes discussion sur 2 articles différents!!

          Autre solution, pourquoi ne pas importer les commentaires du journal sous unue autre forme pour les distinguer (couleur, block spécial caché par défaut,...)

          En écrivant présentement ce commentaire, je me rend compte en même temps que ca va allourdir l'interface, surtout pour un nouveau venu.

          Pourquoi ne pas mettre une option dans les préferences? (connaissant templeet, vous allez sûrement me dire que ça sera pour la version RoR ;)
          • [^] # Re: Hmm

            Posté par (page perso) . Évalué à 7.

            >>> Mais les lecteurs des dépêches sont aussi les lecteurs des journaux. Je ne pense pas qu'il y ai beaucoup de gens qui ne regardent *que* les dépêches et qui se refusent à cliquer sur le moindre jourNal...

            Pas mal de gens sont abonnés au fil RSS des dépêches et ne lisent pas les journaux.
            Oui moi aussi ça me dépasse qu'on ne passe pas sa journée à lire LinuxFR mais bon c'est leur choix ;-)
            • [^] # Re: Hmm

              Posté par (page perso) . Évalué à 3.

              Je suis sur qu'ils ne lisent pas les journaux parce qu'ils passent leur journée à glander sur Facebook ... Révoltant! Mieux vaut mouler sur DLFP...
              • [^] # Re: Hmm

                Posté par (page perso) . Évalué à 2.

                Non y'en a qui lisent que les news parce que c'est la première page et que ça évite de passer trop de temps sur DLFP :)
  • # Simplement tout faire par OpenGL

    Posté par (page perso) . Évalué à 6.

    Ahem. Pour cela il faudrait que les pilotes de toutes les cartes graphiques fonctionnent à merveille sous Linux, y compris dans les anciennes distributions Linux. À moins que la version qui va suivre Firefox 4.0 ne souhaite pas supporter les distributions Linux ayant plus de 6 mois ?

    Je me souviens de mon expérience avec OpenGL il y a quelques années : on avait passé le moteur du jeu Wormux de SDL à OpenGL (lors du passage de ClanLib 0.6 à 0.8 si je me souviens bien). Plusieurs joueurs sont passés de 30 à 50 images par seconde à moins d'une image par seconde : jeu injouable. (Par contre, certains joueurs ayant la bonne carte graphique avec le bon pilote -genre Nvidia et le pilote proprio- avaient un jeu plus rapide.)

    Les développeurs de ClanLib voulaient simplifier leur code en imposant OpenGL... sauf que les pilotes OpenGL sous Linux, c'était pas ça. J'avais tenté de réintégrer le support de SDL dans ClanLib, mais c'était assez complexe, je n'avais pas eu le temps de finir et les développeurs ClanLib ne m'ont pas vraiment soutenu.

    Finalement, on a pris la sage décision de migrer directement à SDL, et depuis tout va bien côté rendu graphique :-) Il me semble d'ailleurs que SDL peut utiliser OpenGL en interne (si on active une certaine option ?).
    • [^] # Re: Simplement tout faire par OpenGL

      Posté par (page perso) . Évalué à 5.

      Mais là, avec cette suite de test WebGL, ça donne quand même un sacré référentiel pour que globalement tout marche mieux.

      Ça va donner pour les pilotes (dont les dévs voudront bien regarder ça) une bonne base commune.

      Cela amène un grand espoir, non ?
      • [^] # Re: Simplement tout faire par OpenGL

        Posté par . Évalué à 2.

        sauf pour du vieux matos ou les cartes n'auront pas les extensions qu'il faut et du coup cela sera un rendu soft par mesa et la les perfs risquent d'en prendre un sacre coup...

        mais bon un jour ou l'autre il faut faire table rase pour pouvoir avancer et vu le merdier que sont les drivers c'est peut etre le moment.
        • [^] # Re: Simplement tout faire par OpenGL

          Posté par (page perso) . Évalué à 2.

          WebGL ne requiert que OpenGL ES 2.0 et une ou 2 extensions 'universelles' (qu'on trouve partout) (ou l'equivalent par OpenGL 2.1).

          Il y a en effet un projet de rajouter des extensions a WebGL mais pour le moment il n'y en a qu'une (proposee par Google) et nous ne l'implementons pas encore.

          Donc, bugs mis a part (bugs dans firefox, dans les pilotes, dans les tests) tout le monde devrait avoir les memes resultats.
          • [^] # Re: Simplement tout faire par OpenGL

            Posté par . Évalué à 2.

            Je ne parlais pas que pour firefox. Il semble qu'il y a une evolution vers du tout OpenGL (ce n'est pas une critique mais une constation) et je pense que certains ordis un peu ancien risque d'avoir du mal.
            • [^] # Re: Simplement tout faire par OpenGL

              Posté par (page perso) . Évalué à 4.

              Je perçois aussi cette évolution, mais la raison me fait renoncer à mes inquiétudes: cela fait presque 10 ans que tous les pc de bureaux sont vendus avec une carte 3D, un petit peu moins pour les portables, ce qui signifie qu'il faut vraiment aller chercher du matériel vraiment ancien pour qu'il n'y ait pas d'accélération 3D basique. En même dans ce cas, on peut rajouter une carte 3D ancienne de récup.

              Ce qui signifie que d'ici à très peu d'années, on ne rencontrera sans doute plus d'ordinateurs sans carte 3D basique, même pour du matériel suffisamment ancien pour qu'il ne coute plus rien ou pour une installation ancienne!

              Mathias
              PS: et j'ai maintenu un PC sur lequel une matrox millemium 1 tournais jusqu'à noël dernier, mais c'était vraiment par manque de temps pour mettre à jour...
              • [^] # Re: Simplement tout faire par OpenGL

                Posté par . Évalué à 1.

                Ça fait déjà quelques années qu'on se retrouve au pire avec un Intel GMA qui supporte OpenGL 2.1.
                Si on compte que les ordinateurs portables ont une durée de vie un peu inférieure, je dirais même qu'il faudrait compter un peu moins de 3 ans avant du matériel compatible partout.
                • [^] # Re: Simplement tout faire par OpenGL

                  Posté par (page perso) . Évalué à 2.

                  Il faut également ajouter qu'il existe sur Linux plein d'alternatives très légères pour ce "vieux" matériel. Que ce soit en navigateurs web, en gestionnaires de fenêtres, ou n'importe quoi d'autre.
              • [^] # Re: Simplement tout faire par OpenGL

                Posté par . Évalué à 7.

                Ce qui signifie que d'ici à très peu d'années, on ne rencontrera sans doute plus d'ordinateurs sans carte 3D basique,
                C'est bien beau d'avoir une carte 3D, mais sans driver c'est la même chose qu'une carte pas 3D...

                Et quand je vois le mal que les dev ont pour supporter la 3D sur une génération donnée, je me dis que c'est pas gagné.
                Et les pilotes proprio ne maintienne pas le vieux matos
  • # html5 & co

    Posté par . Évalué à 3.

    C'est bien le web3.0 avec html5, webgl & co.

    Sauf qu'avant au pire pour accéder a des fonctionnalité avancé il fallait flash, maintenant il va falloir :
    - un navigateur a jour (exit les vieux navigateur)
    - un navigateur qui supporte les bon codecs
    - un os qui supporte correctement opengl
    [...]

    Si les webmaster ne prévoit pas un mode de rétro compatibilité [1], on risque de ce retrouver avec un web de moins en moins portable (et tout ca pour des fonctionnalités parfois bien discutable) .

    [1] on me souffle a l'oreille que la nouvelle version de linuxfr RoR en html5 ne fonctionne pas avec les broswer un peu vieux.
    • [^] # Re: html5 & co

      Posté par (page perso) . Évalué à 7.

      - un navigateur a jour (exit les vieux navigateur)

      Ca, il t'en faut un de toute facon, ne serait-ce que pour des raisons de securite (mises a jour).

      - un navigateur qui supporte les bon codecs

      Si les codecs vraiment libres tels que WebM et Vorbis prennent le dessus, ce probleme sera regle: tout le monde pourra les supporter a peu de frais.

      - un os qui supporte correctement opengl

      Seulement si tu veux utiliser les fonctionnalites en question.

      Si les webmaster ne prévoit pas un mode de rétro compatibilité [1], on risque de ce retrouver avec un web de moins en moins portable (et tout ca pour des fonctionnalités parfois bien discutable) .

      Il existe deja des bibliotheques JS qui utilisent WebGL quand il est disponible et Canvas/2D sinon. C'est aussi ce que fait la version experimentale de google streetview.

      Flash, pour toi, c'etait portable? Les gens font deja des jeux videos en Flash, aujourd'hui. La question est de savoir si tu veux que Flash continue d'etre LA plateforme pour les applications graphiques pseudo web, ou si tu veux pas plutot qu'on ameliore les standards du web pour qu'il n'y ait plus besoin de Flash.
      • [^] # Re: html5 & co

        Posté par . Évalué à 5.

        Si les codecs vraiment libres tels que WebM et Vorbis prennent le dessus, ce probleme sera regle: tout le monde pourra les supporter a peu de frais.

        Vu que Google semble degager tout ce qui a trait a H264 cela semble bien parti tout de meme. Je me demande si la decision de faire cela ne vient pas du ras le bol de se faire attaquer pour des brevets a la con par tout le monde. On peut d'ailleurs remarquer que Google n'a, pour le moment, toujours pas utilise ses brevets en mode attaque!
    • [^] # Re: html5 & co

      Posté par . Évalué à 5.

      [1] on me souffle a l'oreille que la nouvelle version de linuxfr RoR en html5 ne fonctionne pas avec les broswer un peu vieux.

      Ils devraient ajouter un <blink> de compatibilité avec Netscape Communicator.
    • [^] # Re: html5 & co

      Posté par (page perso) . Évalué à 1.

      Il faut bien laisser un chance à Adobe de nous pourrir tout nos PC avec ses nouvelles versions de son virus Acrobat. Si le web devient trop beau et ne bouge pas assez, on n'aura plus de daube à nous mettre sous la dent ;-)

Suivre le flux des commentaires

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