Internet Explorer 11 krijgt ondersteuning voor WebGL en Spdy

De nieuwste versie van Microsofts Internet Explorer-browser heeft ondersteuning voor de WebGL-api en het Spdy-protocol. Internet Explorer 11 maakt onderdeel uit van Windows 8.1, waarvan Microsoft een preview-versie vrijgegeven heeft.

WebGL maakt het mogelijk om binnen de browser de OpenGL-graphics-api aan te spreken. Daardoor kunnen geavanceerde 3d-graphics in de browser gebruikt worden. WebGL wordt al gebruikt in bijvoorbeeld de Citadel-demo van Epic, die draait op de Unreal-engine. Ook Googles nieuwe versie van Maps, waarvoor momenteel een bètatest loopt, maakt gebruik van WebGL om steden en gebouwen te renderen in 3D. Microsoft is redelijk laat met ondersteuning voor WebGL; Chrome en Firefox ondersteunen het al standaard, terwijl het in Safari en Opera handmatig te activeren is.

Naast WebGL kan IE11 ook overweg met het Spdy-protocol, een http-alternatief dat door Google is ontwikkeld. Spdy werkt net als http bovenop tcp, waardoor dat laatste protocol niet vervangen hoeft te worden en een overstap naar het snellere Spdy veel makkelijker is. Groot voordeel van Spdy is ook dat het tegelijkertijd met http kan worden aangeboden. De nieuwe versie van de http-standaard, versie 2.0, wordt ontworpen met Spdy in het achterhoofd: http 2.0 heeft elementen van het Spdy-ontwerp overgenomen.

Spdy was al beschikbaar in Firefox en Opera. Nu ook Internet Explorer met Spdy overweg kan blijft Safari over als enige grote browser zonder Spdy-ondersteuning. Er zijn overigens maar weinig websites die Spdy ondersteunen, maar de sites die dat wel doen zijn grote namen als Facebook, Twitter en Google.

Reacties (75)

[mvkdev]

Dat is grappig! Eerst komt Microsoft met het verhaal dat WebGL onveilig zou zijn (wat een bs was dat), en nu toch maar...

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

Ze moeten zich bij Microsoft is achter de oren krabben over hoe ze denken met anderen om te gaan in de IT wereld.

[kozue]

MS is altijd nogal allergisch geweest voor alles wat ze niet zelf hebben gemaakt. Eigenlijk willen ze uberhaupt geen OpenGL ondersteuning in Windows (ze wilden het schrappen voor W7), maar door de grote vraag zit het er nog steeds in (al dan niet via drivers van videokaarten). Eigenlijk wilden ze dat je maar Direct3D ging gebruiken op het web, want dat is voor MS een stuk beter. Vooral voor hun monopoliepositie. Gelukkig denkt de rest van de wereld daar anders over en moeten ze nu óf mee, óf de boot missen (en het gebruik van IE nog verder zien dalen).

[Verwijderd]

Zowel FireFox als Chrome maken op Windows gebruik van ANGLE voor OpenGL ES 2.0 ondersteuning, dat alles vertaalt naar Direct3D.

[Zyppora]

OpenGL en Direct3D vertalen het weer naar een low-level taaltje waarmee de vidcard driver overweg kan, die het weer vertaalt naar een output signaal voor je monitor die het weer vertaalt naar pixels. Wat ermee gebeurt is an sich niet zo spannend. Het gaat er vooral om dat OpenGL/WebGL zich hiermee een flink marktaandeel toe-eigent, ten koste van een eventuele implementatie van Direct3D. Developers focusen zich dus op OpenGL ipv Direct3D. Microsoft wil dat niet, dus ondersteunen ze het niet. Heeft het niet het gewenste effect? Dan krijg je dus dat ze achteraf alsnog proberen mee te varen, en krijg je bovenstaand artikel als resultaat.

[Verwijderd]

Het punt van MS was dat als WebGL direct bovenop OpenGL zou draaien, dat webpagina's dus ook direct gebruik konden maken van exploits in OpenGL drivers.
D3D heeft een ander ontwerp, met een common runtime tussen driver en applicatie. In deze laag kan dus ook makkelijk extra beveiliging opgenomen worden, en veiligheidsproblemen makkelijker opgelost worden (hoeft niet in iedere driver apart te gebeuren).

Aangezien zowel FireFox en Chrome gebruik maken van Direct3D met een vertaalslag, geven ze Microsoft daarin gelijk. Ik neem aan dat de implementatie van MS zelf ook niet direct op OpenGL draait.

[kozue]

En dat punt van MS was complete BS want ook in OpenGL praat je niet direct tegen de driver/hardware maar tegen een OGL library. Net als met DX dus.

En Mozilla en Google geven MS helemaal geen gelijk. De grootste reden om D3D te gebruiken op Windows is omdat het altijd werkt, aangezien het meegeleverd wordt. OGL wordt door MS tegengewerkt en werkt waarschijnlijk alleen behoorlijk als een gebruiker een "echte" videodriver, zoals die van AMD of Nvidia, geïnstalleerd heeft. Als ik Mozilla of Google was zou ik ook willen dat mijn product op zoveel mogelijk systemen out-of-the-box bugvrij werkt en hetzelfde doen.

Maar wat ze als backend gebruiken doet er eigenlijk niet toe. Het blijft nog steeds dezelfde cross-platform API. Net zoals Windows games onder Linux (via wine) ook op OGL draaien, door D3D calls naar OGL te vertalen, maar intern nog steeds "DX" praten.
Sterker nog, zo'n extra laag geeft alleen maar aan hoe sterk MS onzin aan het lullen was. Blijkbaar werkt WebGL nog steeds prima als je er een DX laag tussen zet. Hoezo "exploiten van driver-bugs"?
Óf MS weet niet waar ze het over hebben, óf MS liep gewoon expres fud te verspreiden omdat ze liever DirectWeb3D ofzo hadden gezien. Als maker van zowel drivers, 3d engines, games als browsers, vermoed ik sterk het 2de.

[Verwijderd]

"En dat punt van MS was complete BS want ook in OpenGL praat je niet direct tegen de driver/hardware maar tegen een OGL library. Net als met DX dus."

Zou je je niet eerst eens inlezen? Bij OpenGL wordt de API door de driver zelf geimplementeerd. Je praat hier dus WEL tegen de driver aan.
Bij Direct3D praat je tegen een common runtime aan, die door MS wordt verstrekt. De driver is een laag daaronder.

"En Mozilla en Google geven MS helemaal geen gelijk. De grootste reden om D3D te gebruiken op Windows is omdat het altijd werkt, aangezien het meegeleverd wordt."

Niet helemaal waar. Het gaat er ook om dat OpenGL drivers dus onderling nogal wat compatibiliteitsproblemen hebben (sowieso is WebGL gebaseerd op OpenGL ES, en zijn de meeste OpenGL drivers niet, of maar deels compatible met ES). Dit komt dus door dat verschil hierboven: de API wordt complete door de driver geimplementeerd, er zitten dus verschillen in de implementatie van vendor tot vendor.
Bij Direct3D gebruikt iedereen dezelfde runtime library van MS, met dezelfde shader compiler etc.

"OGL wordt door MS tegengewerkt en werkt waarschijnlijk alleen behoorlijk als een gebruiker een "echte" videodriver, zoals die van AMD of Nvidia, geïnstalleerd heeft"

Dat is ook al een tijdje niet meer waar. Microsoft verstrekt via Windows Update gewoon complete driverpakketten van Intel, nVidia en AMD, inclusief control panel en OpenGL component.
Microsoft werkt OpenGL absoluut niet tegen (als ze dat zouden willen, konden ze gewoon de opengl32.dll uit Windows halen, dan bestaat de ICD niet meer, en kunnen OpenGL drivers zich niet meer registreren).


"Als ik Mozilla of Google was zou ik ook willen dat mijn product op zoveel mogelijk systemen out-of-the-box bugvrij werkt en hetzelfde doen."

En daarom is het dus beter om te vertalen naar een robuuste API als Direct3D, ipv op OpenGL te richten, ondanks dat OpenGL al jaren standaard op iedere Windows-PC te vinden is.

"Óf MS weet niet waar ze het over hebben, óf MS liep gewoon expres fud te verspreiden omdat ze liever DirectWeb3D ofzo hadden gezien."

Voorlopig zie ik vooral dat jij niet zo goed weet waar je het over hebt, en je verspreidt ook nogal wat FUD.
MS maakt een prima punt op zich, qua security. Ja, natuurlijk zal het ook wel een rol hebben gespeeld dat ze liever een taal zagen die wat meer leek op hun Direct3D. Maar dat betekent niet dat er geen kern van waarheid in zit.

Carmack was het met MS eens: https://twitter.com/ID_AA_Carmack/status/81732190949486592
Mozilla is zich ook bewust van de risicos van WebGL: http://blog.jprosevear.org/2011/05/13/webgl-security/
Khronos is er ook druk mee bezig: http://www.khronos.org/news/permalink/webgl-security
Een proof-of-concept van WebGL exploits is er namelijk al: http://www.contextis.co.u...ore-webgl-security-flaws/

Dus, ik zou zeggen, bestudeer de materie nog eens aandachtig, en laat die grote mond voortaan achterwege.

[Verwijderd]

Het gaat er vooral om dat OpenGL/WebGL zich hiermee een flink marktaandeel toe-eigent, ten koste van een eventuele implementatie van Direct3D. Developers focusen zich dus op OpenGL ipv Direct3D. Microsoft wil dat niet, dus ondersteunen ze het niet.

Da's echt niet het probleem. Microsoft wilde ook geen implementatie op basis van Direct3D. Het is een webstandaard, en developers gaan die slechts gebruiken als die breed ondersteund wordt en dus cross-platform is. Microsoft heeft enkel belang bij native applicaties voor Windows. Toen WebGL verscheen hadden ze dus de strijd al verloren alvorens ze echt begonnen was.

De reden waarom ik ANGLE vermeldde is omdat het hun drogredenen ontkracht.

[Verwijderd]

IE9/10 hebben geen rariteiten nodig en kunnen native HTML compileren en uitvoeren met hardware acceleratie alsof het een .exe is.

Geef eens een voorbeeld van een 3D applicatie in HTML die IE kan uitvoeren alsof het een executable is?

Voorbeeldjes van WebGL:
http://www.senchalabs.org...GL/examples/worldFlights/
http://www.playtankworld.com/level/island_of_oblivion

Verder kent Chrome ook native ondersteuning via Native Client. Daarmee kan men bijvoorbeeld dit:
https://chrome.google.com...neaploeinlbaaodn?hl=en-GB

Dus wat is het exact dat IE beter zou kunnen volgens jou?

[Verwijderd]

html5 is in ie hardware accelerated. Daar is geen webgl plugin voor nodig.

Onder welke steen heb jij geleefd? Alle andere grote browsers maken ook al gebruik van de GPU voor HTML5 weergave. En WebGL is geen plugin maar een standaard (doch optioneel) onderdeel van HTML5.

dat ik omlaag gemod word omdat mensen het verschil tussen een html document viewer en actief draaiende code niet weten is wel weer komisch.

Je wordt omlaag gemod omdat andere browsers duidelijk veel meer zijn dan een HTML document viewer, en ook actief code draaien. Dus ofwel ben je arrogant door ontwetendheid, ofwel een troll. Je hebt geen enkel bewijs geleverd dat Internet Explorer fundamenteel beter zou zijn.

ga anders lekker msdn/technet blogs lezen als je precies wil weten hoe het technisch in elkaar hangt.

Verwijs eens naar een paar specifieke artikels.

Ga anders lekker eens Chrome downloaden en probeer het uit op http://www.chromeexperiments.com/webgl/ Probeer dan eens hetzelfde met Internet Explorer en zie hoe ver het geraakt met de hele webpagina "als een executable" te renderen.

[Junketsu]

Even een side-note: http://www.chromeexperiments.com/webgl/ is een beetje "Wij van WC-eend raden WC-eend aan". Met de Google Chrome webbrowser naar een Google show-off site gaan is niet zo spannend.

Desalniettemin vraag ik mij ook af of IE alles draait op die site, maar ook of FireFox en Safari dit doen.

[Verwijderd]

Inderdaad, want Chrome gaat enorm onderuit op bv http://www.unrealengine.com/html5/
(Ja echt enorm, je hele browser window crasht).
FireFox draait dat zonder problemen.

Mijn ervaring met WebGL-spul tot dusverre is dat het meeste alleen draait in de browser waarin het ontwikkeld is. Vaak gaat het zelfs stuk als er een nieuwe versie van die browser komt.
WebGL heeft kennelijk nogal wat kinderziekten.

Daarnaast is het jammer dat er het IEWebGL project is, maar dat niemand daar support voor inbouwt: http://iewebgl.com/
De initialisatie van IEWebGL gaat iets anders, omdat het IE-canvas zelf niet direct WebGL ondersteunt. Maar met 2 of 3 regels code kun je WebGL spul maken dat op zowel 'echte' WebGL als op IEWebGL werkt.
Beetje jammer dat dit door alle WebGL ontwikkelaars totaal genegeerd is. Maarja, IE11 maakt het gelukkig overbodig.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:21]

[batjes]

Ik vind het eerder jammer dat ze zich een beetje terug trekken van geheel HTML/javascript uit te voeren als applicaties. En de weg van Mozilla/Google maar opgaan.

Voor leuke effectjes, games of andere grafische meuk is niet direct webgl nodig.

Helaas gebruikt MS eigen meuk zoals gestures bij sommige, maar probeer wat HTML testdrive benchmarks en zie het verschil zodra WebGL niet gebruikt word.

[Verwijderd]

Even een side-note: http://www.chromeexperiments.com/webgl/ is een beetje "Wij van WC-eend raden WC-eend aan".

Ik had niet de intentie om naar een Chrome-specifieke site te verwijzen. Het is louter een mooie collectie WegbGL-applicaties. Ze draaien ook prima met FireFox, en neem van mijn part gerust een andere site. M'n enige punt is dat Internet Explorer achter staat qua visuele en interactieve ervaringen op het web, en 'batjes' kennelijk denkt dat het andersom is.

[batjes]

Ga anders zelf browser geschiedenis lezen. Ouderwetse browsers zijn document viewers. Firefox en Chrome werken nog zo, alhoewel ik me nog niet ingelezen heb over de nieuwe Chrome engine, maar betwijfel of ze dit wijzigen.

Ze compilen wel alle 3 javascript naar native code.

En er is een verschil tussen al de HTML over de hardware te gooien en bepaalde aangeroepte elementen.

EDIT: Hier wat leesvoer http://blogs.msdn.com/b/i...rom-ie9-and-your-gpu.aspx
http://blogs.msdn.com/b/i...ith-santa-s-workshop.aspx
http://blogs.msdn.com/b/i...celeration-in-action.aspx
http://blogs.msdn.com/b/i...lable-for-developers.aspx

Zowel Firefox als Chrome hebben hun engines nog niet op de schop gezet sinds dien. Alhoewel Chrome daar nu wel mee bezig is. Firefox en Chrome gebruiken WebGL om dit soort performances te halen. IE moet hier wel in mee.

"hardware acceleratie" en hardware acceleratie.

[Reactie gewijzigd door batjes op 22 juli 2024 23:21]

[PrisonerOfPain]

Nou ja goed, het is natuurlijk niet helemaal onzin wat er in dat artikel staat. Op het moment van publicatie waren er namelijk nog bezwaren over zowel het sandboxen van de uit te voeren code, als het feit dat de drivers nog nooit bloot waren gesteld aan het web en al helemaal niet op security geaudit werden.

De afgelopen twee jaar hebben ze ten eerste de kat uit de boom kunnen kijken mbt de ontwikkelingen van WebGL en ten tweede genoeg ontwikkeltijd gegeven om nu wel een veilige WebGL omgeving te kunnen blootstellen aan het web. Daar zijn namelijk dingen voor nodig als input validatie, maar ook geheugen restricties zodat men er zeker van is dat je niet 'per ongeluk' met je shader in je (shared) ram gaat zitten poken oid, als wel watchdog processen die in de gaten houden dat je GPU niet te lang bezig is met denken.

Verder was de huidige OpenGL implementatie die ze hadden natuurlijk lang niet geschikt - door verwaarlozing en andere zaken, dus verwacht ik dat ze WebGL wellicht gewoon boven op DirectX geimplementeerd hebben. Vooral omdat er geruchten gaan dat HLSL ook ondersteund word.

[PolarBear]

Maar als het verhaal wat ze houden over WebGL zulke BS is heb je dan ook nog argumenten waarom dat is?

[Verwijderd]

Een argument wat ik kan bedenken is dat indien het zo onveilig is, het vreemd is dat Firefox en Chrome dat blijkbaar geen probleem vonden. Zowel Mozilla als Google zijn erg security minded en zullen echt niet zomaar een onveilige API de wereld inslingeren naar meer dan een miljard gebruikers.

Een ander argument is dat het vreemd is dat andere plugins zoals Java en ActiveX wel zijn toegestaan in IE, beiden hebben een twijfelachtig verleden als het gaat om security.

Dus ja, de stelling van Microsoft is op zijn minste verdacht. Ik denk dat het nog even wennen voor ze is dat ze niet langer de baas zijn in de browser wereld, en dat de rest gewoon doorgaat met APIs, met of zonder Microsoft aan boord.

[mcDavid]

Het kan best een argument zijn, maar dat zegt meer wat over hun dan over de standaard. Anderen konden het blijkbaar wel veilig implementeren, als MS dat niet kon was dat hun probleem. Dan maar helemaal niet implementeren is echter wel een erg goedkope "oplossing" waar ze nu dus gelukkig op terugkomen.

[Radiant]

Aangezien je direct met OpenGL bezig bent en dat wordt geïmplementeerd door de videodrivers heb je dus een heel mooi gaatje direct vanaf een webpagina door naar kernel space als er een exploit in een videodriver wordt gevonden. En om dat te fixen ben je dus afhankelijk van updates van de maker van de videodrivers. Hoeveel mensen (gamende tweakers daar gelaten) ken jij die die regelmatig updaten?
DirectX heeft dat probleem niet.
Verre van BS dus.

[Reactie gewijzigd door Radiant op 22 juli 2024 23:21]

[kozue]

Omdat ze D3D naar voren schoven als alternatief terwijl je daar exact hetzelfde over kunt zeggen als wat MS over OGL zei. Er is maar 1 reden dat ze er tegen waren: ze houden niet van open standaarden. Dat is niet goed voor lock-in en monopolies.

[mcDavid]

Gast, heb je ook maar énig idee waar je het over hebt?
Google was de eerste die door had dat het web geen statische omgeving meer is, en daarom met de supersnelle V8 javascript-engine kwam. Op de voet gevolgd door Mozilla met spidermonkey. MS heeft jarenlang ontkent dat dynamiek belangrijk was en hield vol dat tabellen als statische objecten in één keer gerenderd moeten worden. Totaan IE10, toen ze erachter kwamen dat ze toch wel aan alle kanten voorbij gerend werden. Toen kwamen ze ook met veel toeters en bellen eindelijk eens met een fatsoenlijke javascript engine aanzetten. Het zelfde gebeurt nu met WebGL. Nu IE eindelijk een beetje fatsoenlijk mee kan komen op de dynamische webpagina's waar jij het over hebt, is de rest van de wereld al een stap verder, worden er complete browser-based videogames gemaakt en dreigen ze weer de boot te missen.

Als je altijd IE gebruikt hebt kan ik begrijpen dat je IE10 helemaal de hemel vindt, maar serieus haal je kop uit het zand en kijk eens een stukje verder. De andere browsers zaten 5 jaar geleden al op dat niveau.

[kozue]

WebGL is geen plugin maar een standaard. Net zoals javascript en css. Maar ik denk dat jij het verschil toch niet zal begrijpen, aangezien je ook geen idee hebt over browser rendering engines en maar wat loopt te blaten over hoeveel IE met hardware acceleratie doet, terwijl het IE is die een inhaalslag te maken heeft.

[batjes]

Lees mijn andere comment hier boven. Volgens mij weet je zelf niet hoe browsers renderen of wat?

WebGL is geen plugin meer omdat het standaard is
Vreemde redenering maar goed. Jij bent de browser kenner duidelijk.

[Reactie gewijzigd door batjes op 22 juli 2024 23:21]

[MacWolf]

Eerst komt Microsoft met het verhaal dat WebGL onveilig zou zijn ...

John Carmack beweerd ook dat WebGL niet compleet veilig is:

https://www.youtube.com/w...=player_detailpage#t=251s

Het standpunt van John Carmack is dat er vooral security issues in de drivers kunnen zitten. De reden hiervoor is dat GPU drivers in het verleden vooral ontwikkeld zijn met oog op performance, gezien security geen issue was. Maar nu deze drivers (middels WebGL) via een browser aangesproken kunnen worden, zou er gebruik gemaakt kunnen worden van security issues in de drivers.

[Reactie gewijzigd door MacWolf op 22 juli 2024 23:21]

[Verwijderd]

Een groot probleem is ook dat grafische drivers vaak vernieuwen en er dus telkens weer nieuwe issues voor nieuwere drivers kunnen ontstaan.

[Verwijderd]

Dat zorgt net voor extra veiligheid. Hoe ga je als hacker een veiligheidslek exploiten als slechts 0.1% van alle systemen die driver heeft?

Neen, het probleem met toegang te verlenen naar de GPU (door minstens drie lagen heen), is niet erger dan toegang te verlenen tot de CPU (door één laag heen). Die laatste heeft ook toegang tot veel meer gevoelige data. Met de GPU moet je enkel zorgen dat men niet aan afbeeldigen van ingevulde paswoord-velden kan. Maar dat relatief geïsoleerde probleem bestond ook al voor 2D bewerkingen. 3D ondersteuning verandert daar niks essentieels aan.

[Loller1]

Sinds het gerommel met IE6 is Microsoft nogal sterk terughoudend in het implementeren van dingen die niet tot de standaarden behoren of nog niet volledig af zijn. Wat in principe een veel betere strategie is, zeker op lange termijn.

[Dreamvoid]

WebGL *is* fundamenteel onveilig. Via de gpu drivers direct memory access voor willekeurige code van het web is vragen om problemen en gaat tegen elk principe van sandboxing/managed code/etc in. Maar als het hele web het wil gaan gebruiken dan moet je als browsermaker wel mee. Ook al zijn ze er tegen, Microsoft heeft bij lange na niet de macht om het tegen te houden. Implementeren ze het niet in IE, dan komen dezelfde exploits binnen via Chrome/FF.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 23:21]

[Verwijderd]

WebGL *is* fundamenteel onveilig. Via de gpu drivers direct memory access voor willekeurige code van het web is vragen om problemen en gaat tegen elk principe van sandboxing/managed code/etc in.

Onzin. Er is helemaal geen direct memory access via OpenGL ES2. En waarom zou je met JavaScript gecontroleerde toegang mogen krijgen tot de CPU en het hoofdgeheugen, maar niet met WebGL gecontroleerde toegang tot de GPU en het grafisch geheugen? JavaScript vergt veel meer moeite om de veiligheid te garanderen, en toch wordt het aanvaardbaar geacht. Waarom WebGL als onveiliger behandelen?

Om nog maar te zwijgen van de enorme veiligheidsproblemen waar Microsoft zich aan blootstelde met ActiveX. Het is hypocriet om dan het mooi omlijnde WebGL te gaan bekritiseren.

[Verwijderd]

"Om nog maar te zwijgen van de enorme veiligheidsproblemen waar Microsoft zich aan blootstelde met ActiveX. Het is hypocriet om dan het mooi omlijnde WebGL te gaan bekritiseren."

Ik vind dit eerder een wat hypocriete opmerking.
ActiveX is een technologie ergens uit het Windows 95-tijdperk, toen het internet net pas in opkomst was bij de gewone man.
Om dat te vergelijken met een technologie van nu is nogal oneerlijk, wegens voortschrijdend inzicht en dergelijke.
Mag MS geen kritiek hebben op technologie van nu, omdat ze in het verleden ook wat minder veilige technologie hebben gehad? In dat geval zou nooit iemand meer kritiek mogen hebben, want alle browsers, OSen, web servers, programmeertalen etc hebben genoeg fouten gemaakt op dat vlak in het verleden.

Ik zou zeggen: goed dat men leert van hun fouten, en opbouwende kritiek is altijd welkom.

Zie de links in mijn post elders. Mozilla, Khronos en Carmack onderkennen de gevoeligheid voor exploits van iets al WebGL, en proof-of-concepts van DoS en zelfs het stelen van graphics uit het videogeheugen zijn al getoond.

Ik denk ook dat je de zaken wat onderschat. Met JavaScript kun je niet zo makkelijk een DoS doen als met WebGL. Het is vrij triviaal om in een JS-engine een timertje te bouwen, en scripts te killen die te veel CPU stelen. Maar als je dus WebGL calls gaat maken naar de driver, gaat het fout. Vandaar dat Khronos daar dus ook een extensie voor ontwikkeld heeft (die het probleem niet helemaal oplost).

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:21]

[Nactive]

Waarom ondersteund tweakers eigenlijk geen speedy, lijkt mij niet zo moeilijk om in te schakelen of zie ik het zo verkeerd ?

[ACM]

Wat ons betreft is het nog te vaag/ongespecificeerd/ongestandaardiseerd:
- Vziw is er geen ondersteuning in Varnish en wij gebruiken Varnish vollop als reverse proxy. Dus dat gaan we niet zomaar eventjes tussendoor vervangen door "iets" anders dat wel SPDY ondersteund.
- SPDY vereist SSL. Ook SSL wordt niet in Varnish ondersteund en aangezien onze loadbalancers heel goed SSL kunnen "terminaten", maken we dankbaar gebruik van de kracht van Varnish (enorm goede reverse proxy) met die van onze loadbalancers (o.a. ssl-offloading/termination)
- SPDY vereist SSL deel 2. SSL en banners gaan momenteel niet zo best samen, browsers hebben de neiging om content van niet-ssl-domeinen te blokkeren of er waarschuwingen over te geven... En Tweakers heeft nou eenmaal banners nodig om voldoende inkomsten te genereren om uberhaupt servers te kunnen draaien (die bijvoorbeeld weer SPDY kunnen serveren) en mensen aan het werk te houden (die er SPDY op kunnen installeren) En nee, banners en SSL... dat is ook nog een toekomstdroom dat "bannerboeren" daaraan helemaal perfect meewerken.
- De SPDY-ondersteuningen voor o.a. apache lijkt nog niet erg uitgewerkt, de mod_spdy werkt bijvoorbeeld niet zo lekker samen met onze - en de de facto standaard - manier van PHP (aka, pre-fork en niet multi-threaded).

Sowieso zijn er nog meer kandidaten voor HTTP 2.0, dus het is ook nog een beetje afwachten of dit de uiteindelijk "winnaar" van die race wordt, of dat we over een paar jaar de SPDY-support dan weer zouden moeten verwijderen...

We gaan in ieder geval niet "zomaar" even onze Varnish vervangen (bijvoorbeeld door Nginx) en zien het al helemaal niet zitten om onze Apache te vervangen (ook door bijvoorbeeld Nginx).

Ik ben dan ook bang dat het antwoord op "of zie ik dat verkeerd", helaas "ja, dat zie je verkeerd" is

Dus vooralsnog blijven we de kat uit de boom kijken.

[Reactie gewijzigd door ACM op 22 juli 2024 21:40]

[David Mulder]

De ondersteuning is beperkt, maar dat is nog wel te doen zover ik heb uitgezocht, de argumenten op het vlak van SSL zijn een stuk zwaarder. De reden dat Varnish geen SPDY support is dan ook de SSL verplichting ( https://www.varnish-software.com/blog/why-i-dont-spdy ) en daar kan ik me best goed in vinden. Wel jammer, want SPDY heeft zoals dit artikel al aangeeft.

[Aham brahmasmi]

Wel jammer, want SPDY heeft zoals dit artikel al aangeeft.

Wand Spdy heeft wat? Voordelen?

[Olaf van der Spek]

met onze - en de de facto standaard - manier van PHP (aka, pre-fork en niet multi-threaded).

FastCGI is de toekomst, toch? Jammer dat Varnish geen FastCGI ondersteund.

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 23:21]

[sfranken]

FastCGI is toch juist weer afgeschoten? Waarom niet gewoon mod_php gebruiken? Dat werkt tenminste makkelijk.

[Olaf van der Spek]

Hoe kom je daar bij? FastCGI is in principe net zo eenvoudig op te zetten en werkt veel efficienter.

[Damic]

Misschien ene idee/gedoe maar kun je de banners niet zelf op een server ploffen en dan elke keer als die wijzigt zelf alles controleren, heb je ook geen gedoe met malware dragen banners?!

[Verwijderd]

Ach, tweakers werkt ook goed zonder SPDY; waarom iets repareren dat niet kapot is

[_Thanatos_]

SPDY vereist SSL deel 2. SSL en banners gaan momenteel niet zo best samen, browsers hebben de neiging om content van niet-ssl-domeinen te blokkeren of er waarschuwingen over te geven...

Daar heeft de bezoeker natuurlijk geen boodschap aan. Dat is iets dat je bij de leveranciers van de banners kunnen neerleggen, of zelf een fix verzinnen (proxy'en bijv). Maar geen/kapotte banner zal mij persoonlijk een hele dikke worst wezen

Beter nog: zelf hosten. Ben je ook gelijk van een potentieel privacy-gat af. Bezoekers blij, tweakers vrij van 3rd-party cookies.

[Reactie gewijzigd door _Thanatos_ op 22 juli 2024 23:21]

[Cobalt]

Komt IE 11 ook uit voor Windows 7?

[Loller1]

Ja, Microsoft heeft bevestigt dat Internet Explorer 11 voor Windows 8.1 en 7 is. Vreemd genoeg, hebben we nog geen idee of hij ook voor Windows 8 beschikbaar zal zijn. Ook een release datum is tot nog toe uitgebleven.

[Verwijderd]

Aangezien 8.1 een gratis update is zal 8.1 geen probleem zijn.

[Loller1]

Niet iedereen zal zomaar direct updaten naar Windows 8.1 (bv bedrijven), het maakt niet uit of het gratis is of niet.

[Amahoola]

Als het bet als 10 een webbrowser is voor het windows start scherm (w8) dan niet. Maar ik hoop met heel me gar dat ze het voor meerdere windows versies gaan uitbrengen en dat het wat meer de firefox en chrome kant op gaat.

[Loller1]

Mooi. Om ondersteuning van WebGL nu "relatief laat" te noemen, er wordt zelfs gezegd dat het, behalve in Chrome en Firefox, in andere browsers nog standaard geactiveerd moet worden, waar dit bij IE11 al het geval is. Dan zijn ze Apple en Opera nog voor, dus "relatief laat"?

[Verwijderd]

De vraag is nog hoe goed hun ondersteuning ervan zal zijn. Chrome slaagt er inmiddels in om bijna alle WebGL 1.0.2 tests met succes te draaien: https://www.khronos.org/r...gl-conformance-tests.html

Dat heeft Google en TransGaming bijna drie jaar tijd gekost, en inmiddels zijn we bezig met OpenGL ES3 ondersteuning voor ANGLE...

Dus als Microsoft er nu nog maar aan begint, hebben ze nog een lange weg af te leggen. Het grootste probleem is omgaan met onstabiele drivers. Chrome gebruikt daarvoor ANGLE en SwiftShader.

[Loller1]

Ligt het aan mij of is dat vervloekte "compatibliteitsmodus" ding nu eindelijk weg? Man, dat vond ik de enige vervelende feature van IE, maar in IE11 duikt het nergens meer op. Ik heb de browser nu al even getest en het lijk op diverse benchmarks beter te presteren dan de andere browsers. Zelfs de Kraken test en V8 test handelt IE11 beter af dan elke andere browser. Volgens css3test.com ondersteund IE11 nu ook 61% van CSS3. Ik ben benieuwd of Microsoft nog bèta's gaat uitbrengen, of dat dit de laatste versie wordt. Het bevat alleszins al een hoop mooie verbeteringen.

[Verwijderd]

Rare site dat css3test.com
Als je naar de resultaten kijkt staat achteraan dat chrome maar op 5 tests wordt beoordeeld en IE9 op 4700 tests

[Loller1]

Mmm, hier krijg ik voor alle browsers gewoon 935 tests. Misschien een bug?

[Jogai]

"weinig websites die Spdy ondersteunen"
Spdy wordt ook ondersteund door cloudflare tegenwoordig. Dat kan adoptie wel iets versnellen. Zie http://blog.cloudflare.com/introducing-spdy

[Verwijderd]

Kan iemand me uitleggen wat het belang is voor google om Spdy te bedenken? Het gaat volgens mij dan over het sneller kunnen overbrengen van data. Is het belang dan dat google sneller zoek resultaten kan weergeven in browsers van hun dienst-gebruikers? Een heel protocol alleen om die reden?

[Kaalaamaazoo]

Ik zou de details op moeten zoeken, maar ik geloof dat ze die snelheid ook winnen door compressie toe te passen. Compressie is minder data versturen en ookal is het maar een paar kb als je zoveel requests hebt als Google, fb en Twitter wordt je daar wel blij van natuurlijk.

[djwice]

Helaas ook tweaker.net support nog geen SPDY (check het zelf).
Mijn browser wel, en aangezien ik ben ingelogd onder https, zou ik er profijt van hebben.

Wanneer gaat tweakers.net over? antwoord staat hier

[Reactie gewijzigd door djwice op 22 juli 2024 23:21]

[GrimaceODespair]

Opvallend dat MS dan toch indirect SPDY ondersteunt, terwijl ze ook met hun eigen standaard bezig zijn.

Ben ook vooral benieuwd of er ooit een SPDY-addon voor IIS komt, hoewel ik die niet van MS zelf verwacht.

[_Thanatos_]

Even een vergelijkje van IE10 en IE11, plus twee populaire andere browsers (je kan wel raden welke):

http://caniuse.com/#compare=ie+10,ie+11,firefox+22,chrome+29

[Verwijderd]

Er staan veel unknowns bij IE11
Verder staan er zaken die geen standaarden zijn maar propriety elementen zoals WebP (googe image fomaaat), Ogg/Theora (Xiph audio/video formaten).

Het Opus audio formaat staat er ook bij maar dat is tenminste wel een open standaard.
Of het een webstandaard wordt moet nog blijken...

Ook staan er zaken op caniuse zaken als SMIL animations en SVG fonts die effectief reeds obsolete zijn omdat daarvoor de CSS Text en javascript animations specifications worden gebruikt