Google voegt ondersteuning voor WebGL 2.0 toe aan Chrome

Google heeft ondersteuning voor WebGL 2.0 ingevoerd in zijn Chrome-browser. WebGL 2.0 is beschikbaar in Chrome-versies 56 en hoger. Hiermee moeten webgraphics die van deze standaard gebruikmaken beter presteren en krijgen ontwikkelaars meer mogelijkheden.

Op zijn blog laat Google weten dat WebGL 2.0 inmiddels al beschikbaar is gemaakt voor gebruikers van Chrome 56 en hoger, voor zowel Windows, Linux als de Mac. Met versie 2.0 van de grafische standaard moeten de prestaties van webgraphics worden verbeterd. Ook krijgen ontwikkelaars uitgebreidere tools in handen om graphics te maken, en daarmee zou WebGL 2.0 op het zelfde niveau komen als het veelgebruikte OpenGL ES 3.0.

WebGL 2.0 komt ook nog beschikbaar voor Chrome op Android. Een releasedatum is niet bekendgemaakt, maar volgens Google zou de benodigde softwareupdate binnenkort worden doorgevoerd. Mozilla kwam in versie 51 van Firefox al met WebGL 2.0-ondersteuning; die versie kwam begin dit jaar uit. Ook Opera heeft al ondersteuning voor de verbeterde webgraphicsstandaard.

Eerder kwam Google al met verbeteringen voor versie 57 van Chrome, door het reduceren van de achtergrondactiviteiten van tabbladen. Hiermee moet de accuduur beter worden.

WebGL 2.0

Lees meer

Reacties (68)

mikesmit
19 maart 2017 11:21

Kunnen al die browser aub niet beter gewoon zorgen dat ze compliant zijn met css zodat wij niet steeds browser specifieke code moeten gebruiken. Het html5 en css3 verhaal is ondertussen al meer dan 10 jaar bezig en nog steeds heeft niemand volledige ondersteuning. Maar andere "features" worden gewoon maar klakkeloos toegevoegd tussendoor

[Reactie gewijzigd door mikesmit op 19 maart 2017 11:22]

Rex
@mikesmit • 19 maart 2017 11:56

Ik wil bijna zeggen dat dit een flamebait is.
Chrome is al jarenlang de nummer 1 browser qua HTML5/CSS3 support en heeft op html5test.com al bijna een perfecte score (519/555).
Dat Chrome dan tussendoor andere verbeteringen toevoegt, is alleen maar goed, want we willen allemaal dat paginas sneller laden, dat Chrome minder stroom en geheugen verbruikt, dat het browsen veiliger (1) (2) wordt en dat nieuwe features ook worden doorgedrukt (flac, touchbar-ondersteuning, etc...)

Dit zijn allemaal verbeteringen die in 2017 zijn doorgevoerd én de HTML5 score is in dit jaar ook alleen maar omhoog gegaan, dus wat zeur je nou...

TWyk
@Rex • 19 maart 2017 13:06

Chrome is al jarenlang de nummer 1 browser qua HTML5/CSS3 support en heeft op html5test.com al bijna een perfecte score (519/555).

html5test is geen html5 conformance test maar een feature test met een volstrekt arbitraire keuze van welke features er getest worden en arbitraire scoring van wat ze gekozen hebben om te testen en nauwelijks controle of die features volledig of correct geimplementeerd zijn

Een conformance test ziet er zo uit:
https://bakkot.github.io/test262-web-runner/ (ECMAScript)
of zo:
http://test.csswg.org/suites/css2.1/20110111/xhtml1/toc.xht

[Reactie gewijzigd door TWyk op 19 maart 2017 13:26]

Martinspire
@TWyk • 19 maart 2017 13:48

De ene test Javascript en de ander test CSS2.1, dus dat gaat niet eens over HTML5 en CSS3. Maar het klopt dat die html5test ook andere items test. Toch zijn dat wel zaken die devs echt willen of welke nog niet vast staan als officiële standaard, maar dat toch wel snel gaan worden.

Het klopt dat Chrome daardoor extra punten binnenhaalt, maar dat doet nog steeds niets af aan het feit dat Chrome momenteel de meeste standaarden ondersteund. Vooral Safari (waar hij in eerste instantie mee kwam) valt gewoon keihard door de mand omdat het niet vaak genoeg geupdate wordt, zeker op mobiele devices loopt Safari enorm achter.

Loller1

Browsers

@Rex • 19 maart 2017 14:34

Uhm, eerst en vooral is HTML5Test.com al geen CSS3-test en dus wat dat betreft al totaal irrelevant. Ten tweede is HTML5Test ook niet representatief. De score die hier wordt gegeven is volledig arbitrair en daarbij kijkt die test ook alleen maar naar of de browser reageert op een bepaalde feature, niet of die implementatie ook (volledig) correct is en dat laatste durft bij Blink nogal eens vaak niet te zijn.

Rex
@Loller1 • 19 maart 2017 21:56

Uhm, ten eerste heb ik nooit gezegd dat HTML5test.com een CSS3-test is.

Als het een CSS3-test was geweest, dan had het wel CSS3test.com geheten.
Mijn punt was juist dat @mikesmit in zijn first-post meteen liep te klagen over de HTML5/CSS3-support, terwijl Chrome daar juist goed in is.
En dat HTML5test "volledig arbitrair" is, betwijfel is ook ten zeerste. Sure, het test niet de implementatie van HTML5, en dat werkt het valsspelen door browsers in de hand, maar daar wordt al rekening mee gehouden d.m.v. een blacklist. De resultaten komen dus niet al sinds 2010 zomaar arbitrair uit de lucht vallen. Lekker kort door de bocht.

Anoniem: 679062
@Rex • 19 maart 2017 12:14

Hij zegt wel "al die browsers" en daar heeft hij een punt. Ik ben webontwikkeling spuugzat door steeds te sukkelen met het gebrek aan compatibiliteit van al die browsers.

DutchKevv
@Anoniem: 679062 • 19 maart 2017 14:03

Welke browsers moet je nog supporten dat zo'n hel zijn dan? Sinds Android 4.4 is Chrome standaard, Safari === webkit === blink,
Edge heeft goede HTML5 support.

Probeer je google Maps te maken op de Netscape browser ofzo?

Gamebytes
@DutchKevv • 19 maart 2017 16:58

webkit !== blink

OddesE

Browsers
Google Chrome

@Gamebytes • 19 maart 2017 18:56

Maar het veschil is maar heel klein omdat blink een fork is van webkit.

binair
@OddesE • 20 maart 2017 10:29

thja, wat heb daaraan als je weeral eens kunt zoeken waarom iets in godsnaam niet werkt. Naar mijn ervaring is het verschil even groot als tussen (bijvoorbeeld) chrome en firefox...

binair
@DutchKevv • 20 maart 2017 10:27

momenteel ben ik op een (svg) project bezig dat ondersteund moet zijn op Chrome, Safari, Firefox, IE(+11) en Edge. Ik kan je verzekeren dat je vandaag de dag nog steeds voortdurend met incompatibiliteit tussen alle (!) browsers zit. Zowel voor css- als voor svg-support.
Ik zou zelfs durven zeggen dat het nu nog erger is dan vroeger sinds Chrome webkit heeft geforked en je dus nog een extra kit moet supporteren.

Dus nee, safari !== webkit !== blink (en !== IE !==Edge !== gecko).

DutchKevv
@binair • 20 maart 2017 10:42

Aai, ja dan noem je er idd ook wel 1.. SVG heb ik weinig mee hoeven werken, maar weet dat het geen pretje is.

Zou je niet liever gewoon direct met Canvas willen werken dan? Als het toch grafisch moet zijn?

Die heeft al support vanaf IE9

En is een heel stuk sneller in de meeste gevallen.. Heeft aardig wat handige libs om het leven makkelijker te maken (ThreeJS etc) en je kunt zelfs vanaf Blender gelijk models exporteren naar ThreeJS etc

[Reactie gewijzigd door DutchKevv op 20 maart 2017 10:43]

binair
@DutchKevv • 20 maart 2017 12:44

Hebben we onderzocht maar daar hadden we 1 groot probleem mee: ingeladen images worden niet opnieuw gerendered als je inzoomt waardoor je dus detail verliest. En vermits onze app rond die images is opgebouwd hadden we dus niet veel keuze dan met SVG te werken

RielN

Google Chrome

@DutchKevv • 20 maart 2017 12:47

Boh, ik wil een notificatie sturen met een web-app, maar dat lijkt bij Safari/iOS de komende xxx jaar nog geen optie te zijn.

DutchKevv
@RielN • 21 maart 2017 14:05

Tsja.. Als ik daar serieus op reageer word ik afgerekend op flamebait..

Maar anyway, safari zou ook niet meer serieus nemen, al kost het je inderdaad in het begin misschien een customer..

Apple doet zon hard zijn best om je in de app store te houden zodat ze 30% van elke euro in hun zak mogen steken, dat lukt ze niet in een browser..

Dus Apple zal nooit een volwaardige browser neerzetten als dat features uniek aan de app store in de weg gaat zitten.

Ik heb 6 jaar gewerkt op een Macbook en om de zelfde reden overgegaan op windows/linux... IOS apps kunnen namelijk alleen gesigned worden op een Apple device

stel je voor dat alle OS boeren dat zouden doen?? Dan moeten we straks 3 laptops mee naar het werk, 1 voor Mac, 1 voor windows en minimaal 1 voor elke linux distro!!

Doei doei Apple

Ramon
@Anoniem: 679062 • 19 maart 2017 12:27

Misschien eens je klanten ervan overtuigen dat ie 8 niet meer gesupport hoeft te worden

unilythe
@Ramon • 19 maart 2017 14:07

Dat moet je vooral doen als je boze klanten wil die zeggen dat we ons met onze eigen zaken moeten bemoeien.

joldemans
@unilythe • 19 maart 2017 19:10

IE 9 en lager support is gewoon extra uren tellen. Hebben de meeste klanten wel begrip voor hoor.

Gopher
@unilythe • 19 maart 2017 21:18

Je eigen zaken, dat zijn dan toch je eigen zaken?

Als je niet kunt communiceren moet je ander werk gaan zoeken.
Daarnaast ligt het er aan welke support je moet leveren. Moet het werken? Dan zou ik het triest vinden dat dit je niet lukt (van uit gaande dat het normaal webontwerp is en geen specifieke applicaties dan zou het sowieso raar zijn dat het overal moet werken). Vaak hoeft het enkel te werken pixel perfectie e.d. is dan 'n tweede.

Inderdaad ook, als je dat niet kunt verantwoorden om daar meer uren voor te vragen nogmaals. Zoek ander werk, menig kan het wel en hoeft dat ook maar 1x te doen niet per klant een wiel opnieuw uit te vinden.

Je moet gewoon afspraken maken en een prijs leggen tegenover 0.5% van de gebruikers supporten dan willen ze meestal nog tot reden komen.

Knutselmaaster
@Anoniem: 679062 • 19 maart 2017 21:01

Inderdaad, je moet constant al je creaties met alle browsers bezoeken en dan Is het heel vaak zo dat er minstens een niet precies weergeeft wat het zou moeten weergegeven en dan kost het oplossen daarvan meer tijd dan de oorspronkelijke creatie.
En dat terwijl je gewoon de standaard aanhoudt...
En dan is het ook nog eens zo dat dezelfde browser op verschillende platforms niet hetzelfde doet (Chrome desktop ≠ chrome android bijvoorbeeld)

Noedel-Man
@Rex • 19 maart 2017 18:18

Chrome is al jarenlang de nummer 1 browser qua HTML5/CSS3 support

Klopt niet helemaal. Opera is het meest w3c correct

wackmaniac
@Noedel-Man • 19 maart 2017 21:34

Dat was altijd wel zo toen ze nog hun eigen engine bouwden. Tegewoordig gebruiken ze "gewoon" blink. Hierdoor is jouw bewering niet helemaal meer waar volgens mij.

Roel911
@Rex • 19 maart 2017 18:23

...
Chrome is al jarenlang de nummer 1 browser qua HTML5/CSS3 support en heeft op html5test.com al bijna een perfecte score (519/555).
...

Interessante test die: http://html5test.com
Ik heb zojuist ook wat browsers getest;
Opera - versie 43.0.2442.1144 (PGO) - heeft daar 516/555 punten.
Edge - versie 38.14393.0.0 - heeft daar 460/555 punten.
Tor Browser - versie 38.14393.0.0 - heeft daar 377/555 punten.
Firefox versie - 52.0 - 472/555 punten.

Opera, Edge en Tor Browser heb ik onder Windows 10 getest en Firefox op Ubuntu 16.04.

DaveFlash
@Rex • 19 maart 2017 21:29

hmm, ik haal met de laatste versie van vivaldi browser 528/555 op html5test... Zegt dat dan toch iets over de nieuwkomers op de browser markt.....

ro8in
@Rex • 20 maart 2017 14:45

En toch zitten er altijd nog kleine verschillen tussen alle browsers met betrekking hoe zij html renderen..

thomas1907
@pennywise666 • 19 maart 2017 14:37

Wat een onnodige flame post

seba
@mikesmit • 19 maart 2017 15:58

HTML5 en CSS3 zijn living standards, waar steeds features bijkomen. Het is dus niet echt correct om het voor te stellen alsof we er nu al 10 jaar op wachten. Het deel dat ,10 jaar geleden in html5 en css3 zat, is ondertussen overal wel ondersteund

Frenziefrenz
@seba • 19 maart 2017 20:31

Zoals bv. dit simpele lijntje CSS dat al 15 jaar lang werkt in Opera/Presto en Prince.

img[title]::after {display:block; margin-top:1em; content:attr(title)}

Ondertussen is dat overal wel ondersteund. Oh wacht…

Ik ben het wel eens met de strekking hoor.

Het is tegenwoordig allemaal best redelijk, maar even muggenziften mag, toch?

seba
@Frenziefrenz • 20 maart 2017 07:43

Als we dan toch aan het muggenziften zijn, dan moet bovenstaande lijn niet werken volgens de spec:
https://www.w3.org/TR/CSS22/generate.html

Note. This specification does not fully define the interaction of :before and :after with replaced elements (such as IMG in HTML). This will be defined in more detail in a future specification.

Belgar
@mikesmit • 19 maart 2017 12:23

Je hebt wel een punt, maar heeft vaak niets te maken met nieuwe features. Mensen die aan deze feature werken (OS interface) zijn niet dezelfde als die aan layout werken (CSS). WebGL is een grafische API die directe rendering op video resources mogelijk moet maken.

Andere features die deze groep, onder andere, heeft gedaan:

- USB interface standaard (voor U2F onder andere)
- Codecs
- Implementatie van CPU specifieke instructies

Geen van deze dingen heeft enige impact op wat je ziet op je scherm of enige interactie met HTML of andere userland. Dat wordt gedaan door een compleet andere groep met vaak ook compleet andere competenties dan het implementeren van low level system featues

Ed Vertijsment
@mikesmit • 19 maart 2017 11:34

Volgens mij zijn er maar weinig dingen in CSS3 die niet geïmplementeerd zijn in Chrome, Safari/Edge lopen (iets) verder achter. Naar welk deel van de specificatie refereer je?

Overigens worden er bij Chrome aan meerdere dingen tegelijk gewerkt, bijvoorbeeld door es6 te implementeren...

Xieoxer
@Ed Vertijsment • 19 maart 2017 12:06

Dit is niet helemaal waar. Safari en Egde zijn juist de browsers die zich aan de standaard houden. Google pusht heel veel eigen custom implementaties in Chrome, met als doel dat de implementatie wordt opgenomen in de standaard. Google Chrome was vroeger een hele nette browser toen het nog webkit gebruikte, sinds dat ze zijn afgestapt van WebKit zijn ze custom implementaties gaan bouwen. De ontwikkelaars van WebKit wilde juist de standaard volgens ipv een nieuwe standaard bouwen.

[Reactie gewijzigd door Xieoxer op 19 maart 2017 12:16]

Ed Vertijsment
@Xieoxer • 19 maart 2017 15:31

Chrome is in de basis nog steeds een fork van webkit maar groeit steeds veder van de roots af. Het hele proces is dat vendor specifics het naar de standaard halen, zo is canvas als experiment vannuit Apple ontwikkeld.

Chrome is wel meer tech aan het pushen, Apple lijkt safari op een laag vuurtje te hebben en Edge moet nog vooral inhalen...

SuperDre
@Ed Vertijsment • 19 maart 2017 18:39

Komt waarschijnlijk omdat edge bv pas implementeerd als ze ook echt definitief zijn. Chrome doet juist tegenwoordig meer waar men IE6 vroeger van beschuldigde, maar omdat het voor veel webdevs hun favoriete browser is, vinden ze het geen probleem.

Ed Vertijsment
@SuperDre • 19 maart 2017 19:03

Ze breken de standaard an sich niet maar vullen het aan met nieuwe technologieën, daar is niets mis mee. Webgl is ook gewoon een standaard, de implementatie juich ik alleen maar toe

dakathefox
@mikesmit • 19 maart 2017 11:29

Chrome doet dat in de regel toch wel goed?

jer123c
@dakathefox • 19 maart 2017 11:43

Chrome over het algemeen wel, maar als je dan een website design maakt in chrome kan deze er wel eens heel anders uit komen te zien in firefox/opera/IE. Met name de oudere versies van IE hebben hier last van.

kw4h
@jer123c • 19 maart 2017 11:53

Dat is over het algemeen wel verleden tijd. Met hele nieuwe (relatief gezien) CSS features kan dat nog wel zijn, maar voor algemene vormgeving heb ik daar al een jaar of twee geen last van gehad.

418O2
@kw4h • 19 maart 2017 12:16

Dan gebruik je vast geen flexbox of grid?

Anyhow, webgl heeft weinig te maken met CSS. Dat zit elkaar niet in de weg en de implementatie kan parralel. Het is niet of CSS of webgl development

jannes_beterams
@kw4h • 19 maart 2017 12:17

Toch valt mij nog altijd tegen hoe goed je gebruik kunt maken van krachtige features. Er is altijd wel één browser die tegen werkt. Meestal is dat IE of Edge(waarom hebben we deze?), maar ook mobiel valt het steeds vaker tegen. Gelukkig zijn er inmiddels af van het oude IE tijdperk en updaten browsers zelf, afhankelijk van de klant hoeft je deze dan niet altijd te ondersteunen.

Maar algemeen zijn er nog lang niet, kijk maar eens hoe traag het gaat om een mooi iets als CSS er in te krijgen

Ramon
@jer123c • 19 maart 2017 12:15

Alleen als je webkit/blink only dingen gebruikt, dat is dan toch echt je eigen schuld.

dsmink
@mikesmit • 19 maart 2017 12:08

Of browsers niet beter w3c complient kunnen zijn dan andere functionaliteit toe te voegen!?

Ja uiteraard! Maar om dit argument tegen Google Chrome te gebruiken!? Nee! Persoonlijk denk ik namelijk dat Google Chrome zijn zaakjes het beste op orde heeft.

Zelf ben ik ook web developer, voornamelijk backend werkzaamheden dus niet heel veel gezeur met afwijkend gedrag in bepaalde browsers. Echter soms komt er ook nog wel eens wat frontend werk voorbij. Zelf werk ik gelukkig op Linux dus het frontend testen kan ik lekker van me afschuiven. Als het in Chrome en Firefox werkt vind ik het wel gezegend. Daar heb je overigens vrij weinig problemen tussen. Het werkt eigenlijk altijd.

Voornamelijk Internet Explorer wil nog wel eens vervelend doen. Microsoft Edge is gelukkig al een stuk beter en ik kan persoonlijk niet wachten tot de support voor IE11 vervalt. Liever vandaag dan morgen.

De laatste tijd ervaren we eigenlijk meer problemen met Safari. En dan metname als het gaat over functionaliteit die we in een iframe proberen in te bouwen. Hier gaan we gelukkig vanaf zijn met het gebruik van web components.

Ramon
@dsmink • 19 maart 2017 12:20

Dat je op Linux werkt is geen excuus om ie/edge niet te testen, daar heb je browserstack voor.

Ed Vertijsment
@Ramon • 19 maart 2017 19:04

Of een gratis vm van Microsoft met ie/Edge. Vind ik persoonlijk nog fijner dan browserstack...

dsmink
@Ramon • 21 maart 2017 23:09

Omdat ik het niet doe wil het niet zeggen dat het niet gebeurt. Mijn collega test het op zijn Windows machine.

Barsonax
@mikesmit • 19 maart 2017 11:48

Snap zelf ook niet waarom dit nog steeds problemen oplevert. Anno 2017 moet je er toch wel vanuit kunnen gaan dat je website hetzelfde eruit ziet op alle browsers. Nou niet dus...

Martinspire
@Barsonax • 19 maart 2017 13:45

Het grote probleem is dat devices geen updates meer krijgen of gebruikers updates niet installeren. Daardoor heb je dus te maken met oudere support en dus ziet het er niet meer hetzelfde uit. Het is alsof je nieuwe brandstof ontwikkeld, maar steeds rekening moet houden met auto's die tot wel 50 jaar oud zijn. De wet van de remmende voorsprong is hier zeker van toepassing.

Barsonax
@Martinspire • 19 maart 2017 14:33

Maar ook met de laatste versies zijn er verschillen. Dat het erger wordt met oudere versie kan ik nog begrijpen.

Ed Vertijsment
@Barsonax • 19 maart 2017 19:09

Als jij vooral traditionele methodieken toepast gaat dit meestal ook gewoon goed. Zaken als flex maken meer dingen (makkelijker) mogelijk maar vereisen soms wat extra cross platform liefde.

In mijn ervaring zijn het vooral de leaky abstracties van het os die het vaakst issues geven. Zo gedraagt font rendering zich soms conpleet anders tussen platforms (en niet alleen anti aliasing/cleartype). Ook form widgets verschillen omdat die meestal door het OS neergezet worden.

himlims_
19 maart 2017 11:26

http://toji.github.io/webgl2-particles-2/ (webgl van bovenstaande plaatje)

Chris.nl
@himlims_ • 19 maart 2017 12:11

WebGL 2.0 komt ook nog beschikbaar voor Chrome op Android

Bij chrome://flags/#enable-es3-apis kan je WebGL 2.0 al forceren op Android. Je link lijkt het prima te doen met die optie ingeschakeld.

FlemishDroid
@Chris.nl • 19 maart 2017 12:27

Als optie uitgeschakeld/standaard is heb ik bewegend plaatje als het ingeschakeld is heb ik enkel een stilstaand plaatje op mijn S7.

Chris.nl
@FlemishDroid • 19 maart 2017 12:31

Op m'n A5 2017 zie ik standaard / uitgeschakeld niets, en bij ingeschakeld die bewegende afbeelding + touch effecten. 'k Gebruik de laatste Chrome 56x versie uit de playstore. Wellicht dat de implementatie ervan nog soort van beta is, aangezien we verschillende resultaten hebben?

Wolfos
@Chris.nl • 20 maart 2017 10:13

Die flag staat er ook bij Opera, maar ik zie geen verschil bij bovenstaande link. Het werkt wel, maar de framerate is erg laag.

larswienbelt
19 maart 2017 11:22

Aan wat voor toepassingen moet ik denken bij WebGL 2.0? Lijkt me verder te gaan dan in-browser games toch?

johanneslol
@larswienbelt • 19 maart 2017 11:50

https://shadertoyunoffici...6/webgl-2-0-vs-webgl-1-0/

Hier is een mooi lijstje te vinden

Hier een demo van de mogelijkheden >

https://blog.mozilla.org/...an-early-look-at-webgl-2/

Dit is meer technische praat >
https://www.khronos.org/registry/webgl/specs/latest/2.0/

Wolfos
@larswienbelt • 20 maart 2017 10:18

Vooral browser games, maar ook visualisaties. Denk aan een website van een makelaar, waar je een kijkje binnen het huis kunt nemen.

Martinspire
19 maart 2017 13:55

Dan de grote vraag: hoe makkelijk is het om een WebGL 2.0 applicatie te maken die ook nog werkt op WebGL 1.0 browsers? Met als vervolgvraag: hoe lang gaat het duren voordat WebGL brede ondersteuning heeft? Chrome is namelijk erg fijn, maar je kunt geen fatsoenlijke applicatie maken tot Firefox, Safari, Edge (IE zal wel niet lukken denk ik) en ook de mobile browsers het kunnen draaien.

Tenslotte, zijn er al wat leuke WebGL 2 demo's te proberen?

[Reactie gewijzigd door Martinspire op 19 maart 2017 13:58]

JoowrusZ
@Martinspire • 19 maart 2017 15:29

Firefox heeft al sinds versie 51 ondersteuning voor WebGL 2.0... Edge en Safari inderdaad nog steeds niet

leuk_he
@JoowrusZ • 19 maart 2017 17:56

Ik begreep eigenlijk dat ms webgl te gevaarlijk vind: https://blogs.technet.mic...webgl-considered-harmful/ maar dat ging over webgl 1.

Op veel devices eorden video drivers niet geupdate, dus er dreigen daarmee weeg veel mogelijke problemen te ontstaan.

cdwave
@leuk_he • 19 maart 2017 21:19

En terecht.

GL biedt een behoorlijk directe ingang in je video driver. Driver ja. En een driver kan veel meer dan bijvoorbeeld een applicatie met admin rechten kan. Niet echt een deur die je open wil zetten dus. Video drivers zijn gebouwd voor snelheid en niet voor veiligheid of zelfs maar robuustheid. Zeker gecombineerd met Windows' security model van "drivers moeten 't helemaal zelf regelen" biedt dit interessante mogelijkheden voor allerlei duistere figuren. Ik hoop dat ik het gewoon uit kan zetten.

Belgar
@Martinspire • 19 maart 2017 15:39

WebGL is net zo backwards compatible als ES2 vs ES3

Zoals zo vaak is de enige die nog geen implementatie heeft (voor dit soort extended features) microsoft. Safari heeft beta support in de volgende versie en dan heb je dus wel 99% van de mobiele platforms als ze uit beta komen (firefox, safari, chrome, opera)

admin666
19 maart 2017 11:35

Online CAD?

https://www.onshape.com/

Chris.nl
19 maart 2017 12:07

- edit - reactie verplaatst

[Reactie gewijzigd door Chris.nl op 19 maart 2017 12:15]

JJ Le Funk
19 maart 2017 20:19

ik heb een leuk Web GL2 voorbeeld gevonden: http://webglsamples.org/W...form_feedback_separated_2
Bijbehorende bron-code: https://github.com/WebGLS...eparated_2.html#L318-L350
Google Chrome-browser Versie 58.0.3029.19 beta (64-bit) kan hier goed mee overweg.

[Reactie gewijzigd door JJ Le Funk op 19 maart 2017 20:20]

Op dit item kan niet meer gereageerd worden.

Google voegt ondersteuning voor WebGL 2.0 toe aan Chrome

Lees meer

Reacties (68)

Sorteer op:

Weergave:

Tweakers maakt gebruik van cookies

Toestemming beheren

Functioneel en analytisch

Relevantere advertenties

Ingesloten content van derden