Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 153, views: 43.760 •
Submitter: hAl

Microsoft heeft Internet Explorer 10 voor Windows 7 uitgebracht. De browser was al beschikbaar in Windows 8, maar heeft nu ook zijn weg gevonden naar Windows 7. Vista en XP worden niet ondersteund. Windows XP kreeg al geen update naar Internet Explorer 9.

Om Internet Explorer 10 te kunnen draaien is minimaal Service Pack 1 op Windows 7 vereist. Er zijn twee uitvoeringen van de browser te downloaden; een 32bit- en een 64bit-editie. Opvallend is dat de 64bit-download niet twee verschillende browsers installeert. Voorheen werden er op 64bit-edities van Windows aparte 32bit- en 64bit-versies van Internet Explorer geïnstalleerd.

Volgens taakbeheer worden er bij het starten van IE10 op een 64-bit versie van Windows 7 twee iexplore.exe-processen gestart: een 32bit-browserscherm en een 64bit-'Internet Explorer 10 Manager'. Voor iedere volgende tab start de browser een nieuw 32bit-proces op. Via een registertweak kunnen browserschermen ook in 64bit modus werken. Als add-ons geen 64bit ondersteunen, kan dit volgens Microsoft echter tot compatibiliteitsproblemen leiden.

Internet Explorer 10 biedt volgens Microsoft betere ondersteuning voor html5 en css 3. Ook kan de browser beter omgaan met touchbediening. De browser is dan ook vooral ontwikkeld met het oog op gebruik in het op touch-georiënteerde Windows 8.

Internet Explorer 10

Reacties (153)

Reactiefilter:-11530141+199+217+31
Hmm raar, ik heb een helemaal up-to-date Windows 7 x64 installatie, en toch download 'ie nog "required updates" tijdens de installatie.

Maar top dat 'ie er eindelijk is, webdevelopers kunnen dan nog iets langer met Windows 7 blijven rondlopen zonder testmachine met 8. :)
Dit zijn meestal nog updates die na de laatste patch ronden zijn uitgebracht of niet door Windows Update worden genstalleerd omdat de software die ze gebruikte (hier IE10) toch niet op de machine stond.
Sinds IE9 heb ik weer veel vertrouwen in Internet Explorer. Windows 7 en IE9 zijn bij mij altijd stabiel. Kijken hoe IE10 is.
Ik draai IE10 al een tijdje op Windows 7 en ik moet zeggen dat deze uitermate goed werkt en minder compatibiliteitsissues heeft laten zien dan vorige versies. Ik heb nogal wat consoles geopend, dagelijks, die nogal kieskeurig zijn qua browsers, maar IE10 is mij op geen enkel moment tegengevallen.
Mijn eerste indruk is dat het heel snel is en dat ie minder moeite heeft met zware websites. Daarnaast ben ik erg blij dat IE10 zelf automatisch kan upgraden!
Misschien onder de motorkap een stuk beter idd. Echter vind ik de tabs nog steeds lelijk en niet ruimte efficient allemaal. Die adresbalk "naast" de tabs vind ik ongebruiksvriendelijk. Zelf vind ik, en dan niet kijkend naar de render engine en alles toch Chrome wel de meest lekkerste werken qua UI.
Daarom is er dan ook al sinds IE9 RC een optie om de tabbladen er onder te weergeven...
Die adresbalk "naast" de tabs vind ik ongebruiksvriendelijk

Je weet dat je die tabs ook onder de adresbalk kunt plaatsen? :)

Ik moest zelf erg wennen aan de integratie van zoeken en adres. Ik vind het nog steeds een beetje kunstmatig, maar het is inderdaad wel efficienter qua ruimte. Op een tablet pakt die integratie wel goed uit, maar op de desktop minder naar mijn smaak.
Mijn ervaringen met IE10 onder windows 8 zijn anders wel erg gemixt. Hij is beduidend sneller dan IE9, maar ik merk toch wel echt vaak compatibiliteitsproblemen. Een voorbeeld wat ik me nu zo kan bedenken is wat er gebeurde toen ik de timer van mijn router probeerde in te stellen (een Vodafone Easybox die in Duitsland uitgeleverd worden). In plaats van de gewoon bij n entry de tijd te veranderen zat ik ineens met een waslijst aan rare tijden, die zelfs in 113:563 u ofzo erin stonden. Ik ben uiteindelijk bijna een uur bezig geweest al die overbodige entries eruit te halen. Dat ging voorheen met alle browsers die ik heb gewoon vlekkeloos. Ik heb ook al redelijk vaak de compatibiliteitsmodus aan moeten doen voor websites. Ik hoop in ieder geval dat dit zich wat gaat stabiliseren: ik kan me voorstellen dat developers nog niet zo de haast inzien een browser te ondersteunen die pas net uit is en niet echt een grote userbase heeft. Dat verandert nu hij ook voor Windows 7 beschikbaar is.

[Reactie gewijzigd door Buggle op 27 februari 2013 08:38]

is deze browser veel sneller?
Bedankt! Ik heb het getest met SunSpider 0.9.1

IE10 = 167.4ms
Opera 12.14 = 259.8ms
Safari 5.1.7 = 315.0ms
FF 19 = 282.5ms
Chrome 25 = 216.0ms

Wat een verschil!
ter aanvulling

ik heb ook de SunSpider 0.9.1 test gedaan

Opera 12.12= 160,7ms
Opera 12.14= 157,3ms
IE9 32-bits = 625,9ms
IE9 64-bits = 622,8ms
safari 6.0.2 (osx-versie): 290,6ms

[Reactie gewijzigd door dennisdennis12 op 26 februari 2013 16:27]

Heb ook getest en haal met sunspide 0.9.1 :
Total: 100.5ms (ie10)
Total: 135.1ms (chrome laatste iets met 25 geloof ik)
Ik scoor met sunspider FF18 : 145ms. :)
Tweede run 157,6ms.

Is nogal een verschil met jouw score? Waar ligt dat aan?
De machine waarop je de test uitvoerd heeft ook invloed. ;)
Geen idee. Ik heb een FX-6100 met 12GB DDR3 en Samsung 830 SSD met een 120Mbit zakelijke ziggo abbonement. Volgens speedtest een ping van 5ms en 119.8 down en 9.8 up.

Ik heb wel FF19 en geen FF18. Mijn IE10 is 64-bit.

[Reactie gewijzigd door Lisadr op 26 februari 2013 17:43]

Je moet de verschillende browsers op dezelfde machine draaien.

Dus de resulaten van IE10 op PC1 niet vergelijken met die van Firefox op een andere PC.

Dus tot nu toe zijn enkel Lisadr's scores relevant (voor benchmarking; geen idee of deze testen enige real-world relevantie hebben natuurlijk).

[Reactie gewijzigd door Armin op 26 februari 2013 19:39]

Ook al ben ik vr IE, en zeker niet anti-Microsoft, is het testen van een webbrowser waarbij 2 van de 3 voorgestelde tests door MS zelf aangeboden wordt niet heel objectief...
Die tests geven geen radicaal andere cijfers dan de niet-Microsoft tests, dus is dat echt een ramp?
Datzelfde kun je ook over WebKit's sunspider en Google's V8 benchmark zeggen.
IE10 is snel ... verder maakt iedereen een benchmark met de punten die voor hen belangrijk zijn.
Andere test gebruikt Futuremarks Peacekeeper, en IE is inderdaad sneller, maar kan kennelijk minder:

Palemoon 19.0.1 64-bit
http://peacekeeper.future...6jqM&resultId=3012300
1102
HTML5 Capabilities 5/7

IE 10 64-bit
http://peacekeeper.future...6jqZ&resultId=3012326
2618
HTML5 Capabilities 3/7

Beide natuurlijk gedraaid zonder add-ons en dergelijke draaiend. ;)
Ik heb heel veel add-ons op mijn browsers draaien, echter begrijp ik je palemoon score niet. Btw.. Opera rocks ;) met jouw voorgestelde testorgaan ...


palemoon 15(score 2219): http://postimage.org/image/es85sn74j/
ie10(score 2614): http://postimage.org/image/ver5bdrdz/
opera(score 3414): http://postimage.org/image/qj41xj6yt/
Sunspider is tegenwoordig een heel, heel erg slechte test om de performance van een browser te testen. Allereerst zijn de uitvoeringstijden z kort, dat de compiletijd een significante invloed hebben (wat natuurlijk minder boeit bij echte webapps). Ten tweede is Sunspider ontworpen om wat berekeninge te doen, maar dan het resultaat te negeren. Dit triggert in IE dead code elimination, maar vertelt niets over uitvoeringstijd.
Ik snap je reactie niet helemaal, hij onderbouwt toch waarom hij Sunspider niks vindt?
Hij ziet er visueel net als vroeger niet snel uit, maar je merkt een heel groot verschil met de vorige versie van IE wanneer je surft.
Heh, de 64bit versie bevat alleen de 64 bit versie, maar als IE opgestart wordt, worden er zowel een 32bit als een 64bit variant opgestart?
Het lijk me niet zinvol een 64 bits versie te gebruiken van IE.
Die is vermoedelijk trager en neem veel meer memory in beslag.
En waarom vermoed je dat?
Pointers groter & Object alignment leiden tot cache pollution. Kans is vrij groot dat 64 bits niet sneller is dan 32 bits. Nog los ervan dat de browser ook vaak op input wacht van de gebruiker en dan is het zowiezo lood om oud ijzer welke versie je gebruikt.
x86-64 heeft twee keer zo veel registers (16 i.p.v. 8, waarvan twee doorgaans gereserveerd voor de stack). Ondanks een beetje extra geheugengebruik is 64-bit x86 code daarom vaak sneller dan 32-bit.
Pale Moon test ik vaak op snelheid, en de 32bitter is een stuk sneller dan de 64bitter. Bij alle versies.

IE32 heb ik niet getest, maar het zou me inderdaad niet verbazen als hetzelfde verhaal opgaat.
Houd je hier dan ook rekening mee?
Benchmarks invariably perform their tests in "tight loops", which means a small bit of code that is looped through rapidly many times. If properly calibrated (meaning looping through it without performing anything to get a "reference" value) this kind of tight loop can quite efficiently measure how well a specific, single instruction is executed. This is, however, not the kind of behavior you'd encounter when browsing webpages, where you would normally have a large number of different instructions one after the other. Testing in tight loops may therefore not give you any sort of conclusive result; it can only be seen as an indication of what overall browser speed could be if not influenced by other factors.

This also brings me to testing 32-bit and 64-bit browsers against each other. Because of these tight loops and functions in a browser usually not using 64-bit address space or big variables, the benchmarks won't specifically test what a 64-bit browser is strong at. Tight loop testing also brings in another factor: because a 64-bit processor uses twice as large registers, you are inherently pushing twice as much data through your hardware. Tight loops are specifically sensitive to the amount of data that is passed to and from the processor, and you should always take this into account when comparing test results between a 32-bit and 64-bit browser. You can expect 64-bit browsers to score (quite a bit) lower than their 32-bit counterparts; this doesn't mean that the browser is slower, though, just that the test isn't measuring the full capacity of the browser.

[Reactie gewijzigd door Buggle op 27 februari 2013 08:51]

Wel, op een 64-bit van Windows 7, kan je zelfs de 32-bit niet installeren.

Je hebt twee links, de 32-bit link en de 64-bit link.

Eerst de 32-bit link geprobeerd, programma zegt me, dus IE, dat OS niet ondersteund wordt, met de 64-bit geen enkel probleem :)

En zo te zien gaat hij erg rap hier
Al zitten er nog steeds wat kleine irritaties in IE, met name rond download popups en youtube-popup, werkt het met elke versie wel steeds makkelijker.
Nog steeds geen WebGL-ondersteuning, ondanks ANGLE: https://code.google.com/p/angleproject/ (binnenkort geschikt voor Direct3D 11).
MS heeft (imho terecht) beargumenteerd dat WebGL erg onveilig is. Het geeft vrijwel directe hardware access, met alleen de driver als veiligheid optie. Drivers zijn echter niet met het veiligheidsoogpunt ontworpen, waardoor het dus heel goed kan dat dit problemen geeft wanneer websites hier toegang to hebben. DirectX is een betere optie aangezien dat als een extra laag vormt.

Zie: http://blogs.technet.com/...l-considered-harmful.aspx

[Reactie gewijzigd door EvilWhiteDragon op 26 februari 2013 15:48]

Ook directx zou vermoedelijk niet echt veilig zijn als je dat direct kon aanspreken vanaf een internetpagina.
Dan spreek je nog steeds alleen DirectX aan, en niet de low-level OEM drivers zoals dat nu blijkbaar bij WegGL gebeurt.
Dan spreek je nog steeds alleen DirectX aan, en niet de low-level OEM drivers zoals dat nu blijkbaar bij WegGL gebeurt.
Met alle respect, maar waar haal je die onzin vandaan? WebGL is een Javascript API bovenop OpenGL ES 2. De browser heeft hier volledige controle over en kan dus alles controleren. Bovendien maken Chrome en Firefox op Windows gebruik van ANGLE, dat OpenGL ES 2 implementeert via Direct3D 9 (en binnenkort is het ook klaar voor Direct3D 11). ANGLE is open source en veiligheidsproblemen kunnen zeer snel aangepakt worden. Dat zijn dus heel wat lagen tussen WebGL en de driver! Bovendien heeft Microsoft volledige controle over de Direct3D-laag.

En ze beschikken ook over WARP, een software-implementatie van Direct3D 11 met redelijke prestaties. Ze hoeven dus niet eens de GPU te gebruiken. Chrome heeft SwiftShader om op terug te vallen.
De browser heeft hier volledige controle over en kan dus alles controleren
Dat is echter niet waar.
WebGL kan gebruikt worden om binaire data naar de grafische kaart te sturen. Daar kan de browser vrijwel niets aan controleren anders dan de grootte van de hoeveelheid data.

Door die WebGL functionaliteit kan via bijvoorbeeld een lek in een grafische driver van nVidia, Intel of AMD worden geexploiteerd.
Iets wat nu vrijwel ommogelijk is omdat de data die aan de grafisch drivers wordt aangeboden door de browser wordt gegenereerd en niet rechtstreeks van het internet wordt opgehaald.

Probleem is dat het nog jaren zal duren voor het interessant wordt voor malwarebouwers en dan zijn er mogelijk al honderden miljoenen apparaten met een lekke grafische driver exploiteerbaar via webgl en zullen die niet altijd makkelijk te updaten zullen zijn.
WebGL kan gebruikt worden om binaire data naar de grafische kaart te sturen. Daar kan de browser vrijwel niets aan controleren anders dan de grootte van de hoeveelheid data.
Compleet fout. De data zit vervat in Javascript-objecten en de browser kan elke bit daarin controleren voordat het doorgestuurd wordt naar OpenGL ES 2. En in ANGLE kan dat nog een tweede keer gebeuren voordat de data wordt weggeschreven in Direct3D buffers.
Door die WebGL functionaliteit kan via bijvoorbeeld een lek in een grafische driver van nVidia, Intel of AMD worden geexploiteerd.
Geef eens een mooi voorbeeld van zo'n "lek" (en ja, bereid je er maar op voor dat ik zal bewijzen dat het even makkelijk te dichten valt als gelijk welk ander lek).
De browser kan wel elke bit controleren maar alleen als er iets te controleren valt.
En dat is waar het lastig is. Je kunt binaire grafische data niet controleren omdat er niks aan te controleren valt.
Dit heeft in het verleden ook tot stapels lekken geleid in bijvoorbeeld rendering elementen voor gifs en jpegs. Maar die elementen kon Microsoft zelf nog makkelijk patchen en zodra de exploit bekend was konden die bestanden de volgende dag al door malware scanners worden gedetecteerd,
Het niet kunnen controleren van inkomende data leidt nu nog steeds tot bergen lekken in bijvorobeeld PDF's en flashobjecten. De browser kan de data van de PDF of het flashobject wel bit voor bit controleren maar heeft geen infomatie of die data correct / veilig is. Toch is het nog mogelijk voor bijvoorbeeld malwarescanners om bijvoorbeeld PDF's te scannen op bepaalde malware patronen.

Bij data voor grafische drivers is het echter nog problematischer. De binaire malware data hoeft daarbij niet in een los (door malwarescanners scanbaar) bestand zoals een PDF te worden worden geupload maar kan volledig in een script worden samengesteld in een binair weggl data-element zodat het vrijwel ondetecteerbaar is. Verder zijn grafische driver moeilijker te updaten. in bijvoorbeeld een mobieltje vereist het een firmwareupdate en de meeste telefoons krijgen momenteel nooit een firmwareupdate of slecht 1 keer ooit

Misschien als malwarescanners de data tussen browser en grifische driver zouden kunnen scannen dat er dan een vergelijkbare beveiliging zou zijn maar dat is niet erg realistisch denk ik.

[Reactie gewijzigd door hAl op 26 februari 2013 17:08]

De browser kan wel elke bit controleren maar alleen als er iets te controleren valt.
Dus je geeft toe dat je volledig fout was. Zeer nobel.
Je kunt binaire grafische data niet controleren omdat er niks aan te controleren valt.
Tuurlijk wel. Je kan bijvoorbeeld controleren dat de range van een index buffer binnen de grenzen van de vertex buffers vallen. Noodzakelijk voor de veiligheid, maar geen enkel probleem. Ook herschrijven we in ANGLE de shaders om binnen de grenzen van de constant buffers te blijven. Wederom geen probleem.
Dit heeft in het verleden ook tot stapels lekken geleid in bijvoorbeeld rendering elementen voor gifs en jpegs.
Alarm! Laat ons GIFs en JPEGs dan afschaffen!

Neen, dat is duidelijk niet de gewenste oplossing. Evenmin moeten we WebGL aan de kant schuiven omdat er zich lekken zouden kunnen voordoen. Dat is zo voor elke vooruitgang, en die lekken moeten gewoon gedicht worden. Er is niks in WebGL dat niet tot op de laatste bit gecontroleerd kan worden.

WebGL is veel beter afgebakent dan bijvoorbeeld ActiveX, waar Microsoft wel ondersteuning voor biedt. Flash maakt gebruik van ActiveX in Internet Explorer, en Flash ondersteunt Stage 3D, wat op zijn beurt gebruik maakt van Direct3D. Dus zeer bizar waarom Microsoft geen WebGL-ondersteuning zou willen aanbieden met behulp van ANGLE.
...kan volledig in een script worden samengesteld in een binair weggl data-element zodat het vrijwel ondetecteerbaar is.
Nogmaals onzin. Het wordt in z'n totaliteit door de WebGL API ontvangen. Hoe je het samenstelt in Javascript maakt geen zier uit.
Verder zijn grafische driver moeilijker te updaten.
Ja, en? Da's geen beveiligingsprobleem. Nogmaals, alles wordt gecontroleerd in de WebGL-laag.

De compositie maakt ook gebruik van de GPU. Dus gebruikers moeten sowieso een relatief stabiele driver hebben.

[Reactie gewijzigd door c0d1f1ed op 26 februari 2013 19:13]

Mwa, voor Firefox 8 was het nog mogelijk om een screenlogger te maken die de GPU buffer scande. Bij het alloceren van geheugen werd het oude geheugen niet gewist en daardoor kon het beeld van wat op het scherm van de gebruiker gerenderd werd dus gevonden worden.
Zelf heb ik wel eens met WebGL lopen kloten. Onder windows wil de driver nog wel eens vastlopen waardoor windows de driver moest herstarten. Onder linux gebeurde dit ook. Wat er precies vast liep weet ik niet helemaal, maar volgensmij de X server waardoor je die moest herstarten (rebooten was vaak simpeler)

Het is allicht weer een jaar verder en de boel zal allicht hier en daar wat verbetert en stabieler zijn, maar de argumenten die Microsoft aandraagt zijn wel degelijk gegrond. WebGL is gewoon niet heel veilig, ook al kan je er zeker leuke dingen mee doen.
Mwa, voor Firefox 8 was het nog mogelijk om een screenlogger te maken die de GPU buffer scande. Bij het alloceren van geheugen werd het oude geheugen niet gewist en daardoor kon het beeld van wat op het scherm van de gebruiker gerenderd werd dus gevonden worden.
Ja, en dat lek werd heel snel gedicht.

Ook simpele JPEG-ondersteuning kan zo'n lek bevatten door hergebruikt geheugen niet te wissen. Het punt is dat WebGL niet inherent onveiliger is. Er is niks dat oncontroleerbaar is.
Onder windows wil de driver nog wel eens vastlopen waardoor windows de driver moest herstarten. Onder linux gebeurde dit ook. Wat er precies vast liep weet ik niet helemaal, maar volgensmij de X server waardoor je die moest herstarten (rebooten was vaak simpeler)
Da's jammer, maar niet een probleem veroorzaakt door de browser. De browser moet wel zorgvuldig controleren wat er naar de GPU verstuurd wordt, maar als de GPU crasht bij perfect geldige data en commando's dan zit jij met een onstabiel systeem. Ook browsers die geen WebGL-ondersteuning bieden maken gebruik van de GPU voor de compositie!

Als jij een SSD hebt met een brakke driver, moet de browser daar dan ook rekening mee houden? Neen, er is duidelijk een afbakening van de verantwoordelijkheden. WebGL an sich valt veilig te ondersteunen. Als er daarbuiten nog problemen voorkomen, is dat een taak voor NVIDIA, AMD, Intel, etc.
...de argumenten die Microsoft aandraagt zijn wel degelijk gegrond. WebGL is gewoon niet heel veilig, ook al kan je er zeker leuke dingen mee doen.
Je moet goed onderscheid maken tussen de verschillende lagen. Je kan niet WebGL "niet heel veilig" noemen omdat jouw grafische driver crasht. Hetzelfde kan dan voorkomen bij eenvoudige compositie-taken, of een game kan je systeem crashen. Jouw systeem is in zijn geheel onbetrouwbaar zo lang je geen betere driver hebt, en dat kan je dus WebGL niet kwalijk nemen. Da's louter een API, en alles wat heen of weer gestuurd wordt kan gecontroleerd worden, minstens even goed als gelijk welke andere API die op gecontroleerde wijze functionaliteit beschikbaar maakt.

Trouwens, Microsoft is hypocriet: DOS vulnerability in Silverlight 5's 3D. Ook via Stage 3D in Flash is de GPU bruikbaar voor 3D rendering in de browser. Blijkbaar volgen ze dus hun eigen argumenten niet.

Why Microsoft and Internet Explorer need WebGL
Ja, en? Da's geen beveiligingsprobleem. Nogmaals, alles wordt gecontroleerd in de WebGL-laag
Dat is dus juist niet zo.
De inhoud van de binaire data kun jen iet controleren en de range van een buffer controleren door de browser die weggl implementeert klinkt wel veilig maar is in feite zinloos als het lek pas getriggerd wordt bij de grafische driver software.

In de webgl laag kan je enkel controleren dat de data voldoet aan de in webgl opgelegde beperkingen maar in webgl kun je niet controleren hoe de data door de grafische driver wordt verwerkt.

Bij normale rendering van webpagina's wordt de data voor de grafische drivers door de browserengine zelf gegenereerd en niet vanuit het internet aangeleverd. Bij WebGL gebeurt dat in feite wel en komt er door dde browser ruwe binaire data vanaf het internet tot bij de grafische drivers doorgeleverd die slechts beperkt is gecontroleerd.
De inhoud van de binaire data kun jen iet controleren...
"De browser kan wel elke bit controleren maar alleen als er iets te controleren valt."

Jouw woorden. En ja het klopt dat je moet weten waar je op aan het controleren bent, maar nu je woorden terugdraaien en zeggen dat de binaire data niet te controleren valt is pure onzin.

En dat gezegt zijnde, geldt het voor elke web-API dat je moet weten wat er moet gecontroleerd worden, om het veilig te maken. Een lek kan zich praktisch overal voordoen, maar als we daarom alle vooruitgang in technologie moesten tegenhouden zou het web maar een kale plek zijn. WebGL kan veilig ondersteund worden, want alles valt te controleren.

En ja, je systeem zou kunnen crashen als je grafische driver onstabiel is. Maar hoe is dat de schuld van WebGL? Dit is niet anders dan een probleem in het besturingssysteem dat uitgebuit wordt totdat het opgelost is. Er is duidelijk een afbakening van verantwoordelijkheden. Je browser kan niet anders dan er vanuit gaan dat de rest van je systeem zich in bruikbare toestand bevindt. Zelfs voor de eenvoudigste taken is dat een noodzakelijke aanname. Het feit dat grafische drivers doorgaans het minst betrouwbaar zijn, moet niet als excuus gebruikt worden om NVIDIA / AMD / Intel voor altijd slechte drivers te laten schrijven.

Trouwens, de browsers hebben wel degelijk blacklists en/of whitelists voor bepaalde driver-versies, om problemen heel snel te beheersen. Dus het is niet dat ze je aan je lot overlaten als je kwetsbaar zou zijn.
In de webgl laag kan je enkel controleren dat de data voldoet aan de in webgl opgelegde beperkingen maar in webgl kun je niet controleren hoe de data door de grafische driver wordt verwerkt.
Dat kan je net zo min voor de CPU. Kijk maar naar de TLB bug in AMD's eerste Phenom CPU. Die kon in theorie ook misbruikt worden om een systeem te doen crashen. Moeten browsers daar dan ook rekening mee houden? Is elke API onveilig zo lang we niet huis aan huis gaan om Phenom chips te patchen?

Neen, natuurlijk niet. Dus je kan ook WebGL niet de schuld geven van elk driver / firmware / hardware-probleem! Wat hier van belang is, is dat WebGL een ondoordringbare laag is waar alles te controleren valt dat een voor de rest stabiel systeem zou kunnen schaden. Dat is de vereiste die aan elke API wordt opgelegd voordat we die als 'veilig' bestempelen.
Bij normale rendering van webpagina's wordt de data voor de grafische drivers door de browserengine zelf gegenereerd en niet vanuit het internet aangeleverd.
Nogmaals onzin. Ten eerste, de compositie-engine (die ook in Internet Explorer van de GPU gebruik maakt) bepaalt niet de layout van de pagina. Die wordt in de pagina zelve aangeleverd of gegenereerd; data afkomstig van het internet dus. Ten tweede, de browser heeft even veel controle over die data bij zowel gewone compositie als bij WebGL. Het is niet de webpagina die de OpenGL (ES 2) of Direct3D commando's geeft, dat doet de bowser zelve door vertaling van WebGL commando's naar de onderliggende API.
Bij WebGL gebeurt dat in feite wel en komt er door dde browser ruwe binaire data vanaf het internet tot bij de grafische drivers doorgeleverd die slechts beperkt is gecontroleerd.
Larie. Zelfs de shaders worden tot op het kleinste detail gecontroleerd. Ze worden zelfs volledig geparsed en de AST wordt opnieuw uitgeschreven als ESSL, GLSL of HLSL. Niks wordt zomaar van de webpagina aan de grafische API overgedragen.
Met alle respect, maar waar haal je die onzin vandaan?
Met alle respect, die onzin haal ik uit het artikel waar EvilWhiteDragon naar linkte. Of het ook zo is: geen idee, vandaar mijn blijkbaar te subtiele gebruik van het woord "blijkbaar".
Ah, onzin gehaald uit een onzin-artikel, het is je vergeven. O-)

Beter leesvoer: Microsoft's WebGL claims bashed by own employee.
Het geeft vrijwel directe hardware access, met alleen de driver als veiligheid optie.
Vrijwel alle browsers maken nu reeds gebruik van de GPU voor de compositie. Je kan een standaard webpagina schrijven die het de GPU en driver zr lastig maken en mogelijks doet crashen. En hetzelfde geldt ook voor de CPU. Meerdere worker threads in Javascript, en je systeem reageert nog nauwelijks. "Directe hardware access" is een zeer relatief iets.
DirectX is een betere optie aangezien dat als een extra laag vormt.
Hoezo? WebGL gebruikt OpenGL ES 2, wat net zoals Direct3D een grafische API is en dus een "extra laag". Bovendien is de vertaling van WebGL naar OpenGL ook een extra laag waar alles gecontroleerd kan worden. En tot slot, ANGLE implementeert OpenGL ES 2 bovenop Direct3D!
Dan moet Microsoft z'n pijlen niet richten op WebGL. Het is hun eigen software die ze blijkbaar niet vertrouwen.

Google vertrouwt het blijbaar wel, en ze hebben niet eens controle over Direct3D. Ze zorgen gewoon dat hun WebGL naar OpenGL ES 2 vertaling veilig is, en sponsoren ANGLE waardoor ze ook daar heel snel kunnen ingrijpen.

Microsoft heeft niet twee maar drie lagen software om te zorgen dat het veilig is...
Allemaal prima, maar een alternatief bestaat niet.
Hun verhaal kwam op mij over als een flauw excuus. WebGL is zeker wel veilig te krijgen.
Microsoft wil geen GL, ze willen DirectX. Ook strategisch gezien is het voor Microsoft onaantrekkelijk om 3D te supporten in de browser omdat ze dan een makkelijk alternatief geven om te werken in een ander OS. Want tsja.. waarom zou je Windows 8 kopen als alles toch al in de browser draait?

En over het maken van 3D in WinRT:
Zelfs 't maken van een simpele interface in WinRT is nog steeds veel te lastig en nauwelijks compensatie voor 't missen van de WebGL standaard.
Ze hebben een DirectX toolkit, maar die is C++ georienteerd en veel te technisch voor wat de meeste developers willen. XNA is eruit geschopt, waarom weet ik niet.
Er zijn wel .NET initiatieven als SharpDX en ANX, maar dat is allemaal third-party..

Overigens is Google de enige die een beetje goed bezig is. Hoewel... WebGL werkt nog niet in de mobiele Chrome. Het is echter wel mogelijk om via FireFox WebGL te draaien in android.

En Apple lijkt overigens sterk op Microsoft wat betreft WebGL ondersteuning. Van hun verwacht ik niet zoveel.

Eigenlijk zijn alle drie zwak bezig. Maar er is hoop: Zowel Chrome als Firefox lijken binnen afzienbare tijd WebGL ondersteuning te geven op alle platforms! :)
WebGL is geen standaard, dus laat het er maar netjes uit.
En zo zorgt Microsoft er altijd voor dat er een sleur in technologie komt en de browsers weer eens niet vooruit gaan. Het is gelukkig niet meer IE die bovenaan staat. Anders zag het web er veel somberder uit.
Dat hebben ze anders wel met IE6 gedaan, en toen was het ook niet goed.
WebGL is wl een standaard. Het is echter geen noodzakelijk onderdeel van de HTML5-standaard. HTML5-implementaties zonder WebGL-ondersteuning zijn dus perfect standaard, maar dat betekent niet dat WebGL zelf geen standaard zou zijn.

Browsers die wel WebGL-ondersteuning aanbieden, wijken geenszins af van de standaard.

EDIT: bedoeld als reactie op Loller1.

[Reactie gewijzigd door c0d1f1ed op 26 februari 2013 17:56]

Je bedoelt die standaard die nog steeds niet definitief is? dan is het dus ook nog geen standaard..
Jawel, een standaard in progess is nog steeds een standaard. Zoals HTML5 ook een standaard is die nog niet af is maar wel al deels geimplementeerd is in browsers, en volop gebruikt wordt door ontwikkelaars.
Een standaard wil niets anders zeggen dan dat de meerderheid het erover eens is om iets op een bepaalde manier te doen. Of dat een officiele of definitief gepubliceerde 'standaard' is zegt daar niet zoveel over. Ja, de kans wordt vergroot dat alle implementaties uiteindelijk hetzelfde zijn/kunnen zodra er een officile standaard is met het label definitief, maar in de praktijk zegt dat niet zoveel.
Sterker nog, je ziet heel vaak dat dergelijke standaarden juist implementaties in de praktijk volgen, of zelfs dat de implementaties in de praktijk zo'n standaard volledig links laten liggen om wat voor reden dan ook.

In zekere zin had je bijvoorbeeld ten tijde van IE5/6 gewoon bepaalde dingen die MS erdoor gedrukt had; dat was dan 'de standaard'. Hetzelfde geldt voor DOC(X) dat is ook 'de standaard'.
In de (OV) telematica heb je bijvoorbeeld TPEG wat nu al bijna een decennium de standaard is, maar zo goed als geen enkele reizigersapplicatie gebruikt het. Zelfde geldt voor navigatiesystemen; TPEG is intermodaal. Het blijft allemaal het hopeloos beperkte en verouderde RDS-TMC gebruiken.
Aan de productiekant heb je tegenwoordig het europawijde standaard SIRI voor de uitwisseling van real-time timetables in het OV, maar die wordt ook practisch nergens echt gebruikt. In Duitsland zijn ze allemaal bezig met VDV, waar SIRI op gebaseerd is, maar uitegerekend in de USA zijn de eerste pure SIRI implementaties onderweg - terwijl de standaard alleen op Europa gericht is!
Je bedoelt die standaard die nog steeds niet definitief is? dan is het dus ook nog geen standaard..
WebGL 1.0.1 is af. WebGL 1.0.2 zit in z'n ratificatie-periode. WebGL 1.0.3 is in beta. En hoewel dit nog niet bevestigd is, zou het kunnen dat er een WebGL 2 op komst is op basis van OpenGL ES 3.

WebGL is dus wel degelijk definitief. Dat men nog druk bezig is met het verfijnen en uitbreiden van de specificatie wil niet zeggen dat het niet al een standaard is. Nogmaals, 1.0.1 is af en zal niet meer veranderen.
Voor iedere tab start de browser een nieuw proces op basis van 32 bits of 64 bits.
En hoe bepaalt 'ie dan precies of hij een 32-bits of 64-bits proces moet starten? Kijkt 'ie of de pagina addons laadt die geen 64-bits ondersteunen?
Dat knowledge base artikel gaat over Windows 8, en heeft dus vrij weinig met IE10 op W7 te maken.
Helaas, draait niet onder Wine.
Zoals verwacht eigenlijk.
Wel jammer, zou het graag willen draaien, sommige sites zijn ActiveX only zoals mijn IPcamera.
Maar daar zijn ook wel alternatieven voor.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneMobiele besturingssystemen

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013