Windows XP. Par contre ca marche pas avec opera 11.11. Mais ca marche bien avec Chrome.
Windows XP. Par contre ca marche pas avec opera 11.11. Mais ca marche bien avec Chrome.
Ca ne veut rien dire... circonscrite, peut-être?ellipse concentrique à la pièce
OS : WinXP
Outils : VC++ 8 (Visual Studio 2005)
ça veut dire qu'elle a le même centre que la pièce.
Ceci dit, elle est également circonscrite à la pièce.
Opera 11.1 ne supporte pas le webgl. Il sera supporté à partir d'Opera 12.
Opera 11.5 beta supporte le webgl, au moins pour la version windows.
L'article explique aussi que microsoft à une solution pour silverlight.
Par contre je doute que la population de gamer accepte de mettre à jour leur driver avec des patch sécurités ou décide d'acheter des cartes graphiques nouvelles génération plus sécurisée mais plus lentes.
A faire un choix mieux vaut désactiver cette option.
http://www.contextis.co.uk/resources/blog/webgl/
A priori, il n'existerait pas de solution sans compromettre les performances or le fond de commerce des fabriquants c'est la performance. directx, opengl, les shaders ont été créé pour fournir un acces au hardware en minimisant les couches et les controles. On part du principe que le développeur sait ce qu'il fait. Et là on dit que les concepteurs de navigateur vont expliquer gentillement au fabricant en leur disant les mecs "on a merdé, nous avons fait quelques erreurs dans la spécification mais comme on veut pousser cette norme, pouvez vous s'il vous plait revoir vos copies : misez sur la sécurité plutot que la performance"
Tant bien qu'ils feraient preuve de bonne volonté, quel joueur installerait un driver ralentissant sa carte, l'empechant de jouer au dernier jeux qu'il a payer 60€. C'est la remise en cause de toute une industrie (celui du jeux video) dont il est question.
Sinon je salue votre travail
Je pense qu'il est possible de sécuriser le webgl sans compromettre les performances des cartes dans openGL ou directX, d'autant plus que le webgl peut se permettre d'être plus lent qu'openGL ou directX.
Dans le Khronos Group, consortium industriel chargé de la mise au point du WebGL, il y a notamment ATI, Nvidia, AMD, intel pour les fabriquants de cartes graphiques et Apple, la Fondation Mozilla, Google et Opera pour les fabriquants de navigateurs, donc à mon avis c'est qu'il doit y avoir un compromis possible entre performances 3D et sécurité.
La sécurisation du webgl s'effectuera du côté des navigateurs. L'alternative entre une carte graphique peu performante et sécurisée ou performante et non sécurisée me parait totalement improbable.
Après comme dès qu'une nouvelle technologie apparaît, il y a souvent des failles de sécurité au début qui peuvent entraîner des résistances au changement. Elles seront comblées progressivement je n'en ai aucun doute.
Les fabricants de navigateurs ne sont pas plus bêtes que nous : ils savent que ça serait totalement infondé de demander aux fabricants de cartes de baisser la performance au profit de la sécurité, et de plus cela ne résoudrait pas le problème pour celui qui ne veut pas changer de carte graphique. Ils vont travailler avec les fabricants de cartes graphique pour sécuriser leurs navigateurs, et c'est ce qu'ils font déjà.
D'ailleurs au niveau des failles de sécurité, celles qui ont été détectées vont être corrigées sous peu à l'exception de celle du deni de service (source :
http://games.greggman.com/game/webgl...soft-bullshit/ ).
L'attaque par deni de service est également présente avec silverlight 5, le risque n'est que le plantage de le l'ordi. A noter que cette faille n'est présente qu'avec certaines configurations.
Quant à l'envoi direct d'instructions à la carte graphique sans contrôle, c'est un mythe. Je cite :
The other is that the GPU process validates EVERYTHING!!!! before calling the GPU drivers.
It validates all parameters so a webpage can not pass unknown parameters to the GPU.
It validates the size of all buffers created and all access to them. The webpage can not exploit buffer overruns in a driver. This is part of the WebGL spec.
It validates all indices against the size of all buffers that will be accessed during a draw call. This means a webpage can NOT submit indices that would access data outside a valid range. This too is part of the spec.
It validates that all writing to textures is within bounds. This means a webpage can not submit texture data outside the bounds of a texture.
It validates all buffers, textures and renderbuffers are cleared on creation. This means a webpage can not access data left over from other apps or pages. This is part of the WebGL spec. That Firefox had a bug in this area which has already been fixed. It was a bug in Firefox , not a bug in WebGL.
It validates that every GPU object referenced by the WebGL page was created by that page. If it’s not the call is not passed through to the driver.
It validates that the shaders submitted to the GPU use only the minimal features allowed by the spec. That means no dynamic indexing of sampler arrays. It means no infinite loops. There’s actually a huge list of features that native apps would have access do that are disallowed by this validation.
On top of all of that we work around bugs in drivers where possible. Examples of some of these bugs.
Some drivers are buggy in that if you give them a shader with an array of uniforms and only access uniforms at the end of the array they’ll screw up. We work around that.
Some drivers are buggy in that they crash if multi-sampling is enabled. We disable multi-sampling on those drivers.
Some drivers have bugs with long identifiers in shaders. We work around that by re-writing the shaders with small identifiers and then mapping the user’s identifiers to ours.
Some drivers have issues we certain kinds of loops in shaders. We unroll the loops.
Some drivers when asked for an RGB surface will actually return an RGBA surface. We work around this bug as well.
Some drivers don’t return the correct format for array identifiers and/or don’t correctly identify uniform arrays or attribute arrays as arrays. We work around these bugs too.
I’m sure there are other bugs I don’t even remember that we work around.
De ce que j'ai compris pour sécuriser au mieux webGL via le navigateur il faudrait revoir les specs
Mais on est plus à l'époque ou il n'y avait que les "geek" qui utilisaient l'ordinateur dans leur vie de tous les jours. C'est un outil qui prend une autre dimension et il y a de plus en plus d'enjeux economique.
Et mettre à disposition une techno qui merde, que tout le monde sait que ca merde et en disant que les problèmes se regleront au fil du temps, cela s'appelle être irresponsable. On se croirait dans l'industrie pharmaceutique et leur mediator.
C'est une techno qui est clairement pas mûr, comment expliquer sa disponibilité aupres du grand publique sans une mention "à utiliser à vos risque et péril jusqu'à ce qu'on résolve tous les pb connu"
je remarque d'ailleurs que parmis les problèmes connus, on a:
- un ou des souci d'implémentation de la spec
- des pb de driver
- un problème de la spec qui pour être implémenté doit attendre que les fabriquants rajoutent une fonctionalité au sein du GPU (=> prochaine génération)
Tu m'étonnes que microsoft décide d'arreter les frais. Et là, on parle de pb connu.
La différence avec Silverlight, microsoft maitrise toute la chaine ou presque.
Justement, tout le monde n'est pas suffisamment geek pour désactiver le webgl... Quant aux failles, à l'exception du DoS, elles vont être rapidement corrigées. En ce qui concerne le dos, le seul risque est le plantage ponctuel de l'ordinateur suivit d'un redémarrage, et ce pour certaines configurations combinant carte graphique et OS merdique. Entre ça et les ravages du médiator la comparaison est totalement grotesque et ridicule .
Et d'ailleurs on peut aussi planter un PC avec une application flash, silverlight5, ou un javascript malicieux... tout dépend de sa configuration et surtout des sites internets sur lesquels on va. Si tu veux être vraiment safe, désactive le javascript et les cookies tant que tu y es.
Quant à la techno, elle est activée par défaut sur Chrome depuis la version 7, sortie en novembre dernier, et depuis la version 4 de firefox, sortie en avril dernier. Elle est présente sur les navigateur en version béta depuis longtemps, et il n'y a pas eu de gros problème.
Il faut voir aussi que microsoft fait aussi de l'esbrouffe parce que ce n'est pas avec silverlight5 qu'ils vont arriver à d
escendre le webgl, alors ils leur reste ça...
Les fabriquants de navigateurs et de matériels regroupés au sein du Khronos Group ne seront pas assez laches pour tout laisser tomber d'un projet qui consiste à sortir une technologie libre permettant d'afficher de la 3D rapidement, sans plugin dans le navigateur. Il y a quelques problèmes au lancement, transparents pour les utilisateurs, détectés parce que la techno et sortie et le public (dont les hackers) s'y sont intéressés et tant mieux.je remarque d'ailleurs que parmis les problèmes connus, on a:
- un ou des souci d'implémentation de la spec
- des pb de driver
- un problème de la spec qui pour être implémenté doit attendre que les fabriquants rajoutent une fonctionalité au sein du GPU (=> prochaine génération)
Parmi ces problèmes aucun n'est grave : aucun ne permet de pirater tous les ordinateurs compatibles webgl avec un OS donné.
Après comme pour toute nouveauté, dans son adoption il y aura les précurseurs, les suiveurs et les réactionnaires.
Actuellement n'importe qui va a la FNAC, achète le PC le plus bas de gamme, avec windows 7, télécharge Chrome/firefox et le webgl marche très bien. Et puis sur mon PC qui a 3 ans, moyenne gamme, ça tourne bien. Donc pas la peine d'attendre la prochaine génération de GPU pour oser activer le webgl.
Microsoft n'a pas décidé d'arrêter les frais parce qu'ils n'ont jamais mis les pieds dans le Chronos Group, ils n'ont donc jamais tenté d'implémenter le webgl. Ils se sont d'emblé orientés vers silverlight.Tu m'étonnes que microsoft décide d'arreter les frais. Et là, on parle de pb connu.
La différence avec Silverlight, microsoft maitrise toute la chaine ou presque.
Après pour silverlight5 cette technologie comporte les mêmes riques peu ou prou que le webgl ( http://securite.developpez.com/actu/...memes-risques/ ), et elle est aussi sensible aux DoS, même si microsoft maitrise toute la chaine....
En plus, silverlight5 étant encore moins répandu que le webgl, je pense qu'il y a des trucs qui vont être découverts lors de son déploiement massif, parce qu'il n'y a pas de raison de penser que microsoft va faire mieux qu'un consortium regroupant Nvidia, Ati, Amd, Intel, Apple, la Fondation Mozilla, Google, Opera.
Cette discussion va réussir à ressemble à un troll microsoft-linux ou IE-FF si ça continue
Que je sache, sony n'a pas été attaqué parce leur site était en WebGL...
C'est tout le Web qui est une immense faille de sécurité.
Le seul ordi qui est sécurisé, c'est celui qui n'a pas de carte réseau ni de port USB...
Combiner du WebGL avec du PDf, c'est une bonne idée, technologiquement. Du point de vue business, vous n'avez pas peur d'être trop dépendant d'Adobe ? Je veux dire : si votre idée a du succès, ils peuvent assez facilement vous éjecter du marché en intégrant les mêmes fonctionnalités à Acrobat. A mois que votre objectif ultime ne soit le rachat par Adobe ?
Et bien disons que notre objectif n'est pas le rachat par adobe
Un jour on pourra sans doute utiliser autre chose que du pdf (mais pour cela il faut l'implémenter). Si on a choisi ce support, c'est qu'il est largement utilisé, et qu'il est facile d'exporter n'importe quel autre format en pdf (odt, docx...)
Ca ressemble au début du vmrl.
A part être dans un PDF c'est quoi la différence ?
Une nouvelle démo webgl.
Rien à voir avec les pdf mais bon...
http://www.spacegoo.com/solar_system
ps : il s'agit d'un modèle simple d'accrétion d'asteroides autour d'un corps largement plus massif (ici texturé comme saturne).
Ils interagissent gravitationnellement entre eux, et petit à petit, ils s'agregent pour former de gros satellites.
ps : sous windows, il vaut nettement mieux utiliser chrome (jusqu'à 7000 corps alors que FF s'arrete vers 3000 sur ma machine).
En fait, si je comprends bien, votre activité est centrée sur WebGL, et ce mariage avec PDF est un exemple de ce que vous pouvez faire...
J'ai dû ne rien comprendre...
D'où ma question :pourquoi un PDF si l'utilisateur ne peut pas télécharger le document ?
A quoi ça sert ? Juste de fenêtre au conteneur ?
C'est le but d'un document de ce type en général. Pourquoi ne pas avoir plutôt utilisé les navigateurs, qui intègrent l'accélération matérielle ou opengl ?
Exactement
Et bien pour commencer, notre activité est justement centrée sur le WebGL, donc on utilise bien les navigateurs et l'accélération graphique.
Ensuite, le fait de ne pas pouvoir télécharger le document est intéressant pour nos (futurs ) clients. Un journal qui met son contenu en ligne préfère que ses lecteurs ne puissent pas télécharger la version complète du document.
Pourquoi un PDF? J'ai répondu, c'est parce que c'est très simple d'en fabriquer à partir de n'importe quel autre format, et que tout le monde a un Viewer PDF.
Ensuite parce que c'est le format de travail de base des journaux.
ça c'est chaud quand mêmepiloter un hélicoptère en panne
EDIT: marche pas chez moi avec Firefox 5... "could not initialize WebGL"
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
Toutes...
Oui
Par contre j'avais testé sur mon PC chez moi (Windows 7, la carte graphique je sais plus), ça marchait pas, mais ce matin j'ai testé sur mon PC au bureau (Windows XP, ATI Radeon HD 4550) et là ça fonctionne, toujours avec Firefox 5... Donc ça doit venir de mon PC
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager