Microsoft zet previewversie Internet Explorer 9 online
Microsoft heeft op zijn developersevenement MIX een previewversie van Internet Explorer 9 voor developers geïntroduceerd. Versie 9 krijgt onder ander een nieuwe javascript-engine en ondersteuning voor hardwarematige html5-videodecodering.
Microsoft kondigde in november 2009 aan dat er een begin met de ontwikkeling van IE9 was gemaakt. Als belangrijkste doelstellingen werden betere javascript-performance en betere ondersteuning voor css3 en html5 genoemd. Op de developerbijeenkomst MIX heeft Microsoft nu een eerste proefversie van de browser geïntroduceerd. Het gaat om een kale implementatie van de renderengine; zo ontbreken de adresbalk, de terug-knop, en antiphishing- en antimalwarebeveiliging. Ook opvallend is dat Internet Explorer 9 niet onder Windows XP zal werken: Vista met Service Pack 2 is het minimum.
De nieuwe javascript-engine draagt de codenaam 'Chakra' en is een stuk vlotter dan zijn voorganger. In de SunSpider-benchmark is Chakra ongeveer zes keer sneller dan de javascript-engine uit IE8, al blijft Chakra momenteel nog wel achter bij de nieuwste versies van Chrome, Opera en Safari. Een deel van de snelheidsverbetering is gerealiseerd door betere multithreading. Internet Explorer 9 gebruikt bij multicoresystemen namelijk een aparte processorcore om javascript te vertalen. Microsoft claimt dat het Chakra in de komende tijd nog sneller kan maken. Verder gebruikt IE9 de videokaart om het renderen van html5-video en vectorgraphics te versnellen.
In de Acid3-test, waarmee de css-ondersteuning van een browser getest wordt, worden momenteel 55 van de 100 punten gehaald. De vorige versie van Internet Exporer scoorde maar 20 punten. De laatste versies van Chrome, Opera en Safari weten de test al perfect te doorlopen.
Wie de nieuwe features wil bekijken, kan terecht op Microsofts Test Drive-website. Het ontwikkelteam streeft ernaar om elke acht weken een update van de testomgeving uit te brengen.
Reacties (137)
Weet iemand waarom opera 10.10 zo traag is in deze benchmark? Een enorm verschil met 10.5!
Opera gebruikt sinds 10.50 een nieuwe javascript engine. Technisch gezien was de oude een stuk slomer, hoewel dat IMO niet zo aanvoelde.
bijna complete browser is opnieuw opgebouwd. zo heeft men bij linux ook een nieuwe GUI engine gekozen
Nee, de browser is nog hetzelfde. Engine etc. allemaal nog identiek, alleen de javascript engine is iets verbouwd. Dat je 't niet merkt in de echte wereld komt meer omdat javascript maar een beperkt onderdeel is van een gemiddelde website en Opera in de rest altijd al 't snelst is geweest.
De GUI is inderdaad "nieuw" onder linux, maar meer dan de gui en de engine is er echt niet opnieuw opgebouwd. Zou ook zinloos zijn, want beter dan Opera kun je 't in veel gevallen nergens anders vinden. Firefox jat niet voor niets alles wat los en vast zit van Opera en 99% van de extensies voor FF zijn niet voor niets op Opera gebaseerd.
De GUI is inderdaad "nieuw" onder linux, maar meer dan de gui en de engine is er echt niet opnieuw opgebouwd. Zou ook zinloos zijn, want beter dan Opera kun je 't in veel gevallen nergens anders vinden. Firefox jat niet voor niets alles wat los en vast zit van Opera en 99% van de extensies voor FF zijn niet voor niets op Opera gebaseerd.
Nee want er zijn voor één bepaalde functionaliteit soms meerere plugins.
- Er zijn bijvoorbeeld diverse plugins om je google bookmarks te integreren in het browser-menu, als rechtsklik-optie of beide (overigens niet van Opera overgenomen).
- Ook zijn er meerdere session-managers, meerdere tab-optie-plugins, en sommige zijn een cobinatie van die twee.
Verder klopt het wel dat veel plugins Opera-functionaliteit in Firefox integreren, maar 99% lijkt me een beetje overdreven, er zijn ook veel plugins die voor een Europeaan totaal zinloos zijn zoals voor shoppen op een bepaalde us site (del.ico of zoiets) of soms maar enkel werken op één bepaalde universiteit.
- Er zijn bijvoorbeeld diverse plugins om je google bookmarks te integreren in het browser-menu, als rechtsklik-optie of beide (overigens niet van Opera overgenomen).
- Ook zijn er meerdere session-managers, meerdere tab-optie-plugins, en sommige zijn een cobinatie van die twee.
Verder klopt het wel dat veel plugins Opera-functionaliteit in Firefox integreren, maar 99% lijkt me een beetje overdreven, er zijn ook veel plugins die voor een Europeaan totaal zinloos zijn zoals voor shoppen op een bepaalde us site (del.ico of zoiets) of soms maar enkel werken op één bepaalde universiteit.
In de vorige browservergelijkingen was het fanboy-gehalte in Sleep0rz' posts ook al behoorlijk hoog.
Beetje jammer wel want de eerste alinea is best aardig. Jammer dat de stellingen die in de tweede alinea gedaan worden nou nodig zijn.
Beetje jammer wel want de eerste alinea is best aardig. Jammer dat de stellingen die in de tweede alinea gedaan worden nou nodig zijn.
[Reactie gewijzigd door LollieStick op donderdag 18 maart 2010 11:42]
Omdat in 10.5 een verbeterde Javascript engine is geïntroduceerd die sneller is dan de vorige.
@topic. Ik meende mij te herinneren dat MS niet voor de snelste browser ging :x
Achja, niet dat het slecht is.
@topic. Ik meende mij te herinneren dat MS niet voor de snelste browser ging :x
Achja, niet dat het slecht is.
ze zijn toch niet de snelste?
het is niet omdat je niet de snelste hoeft te zijn, dat je de traagste wil zijn...
als iets minder tweaken de code "mooier" kan houden, lijkt mij dat zeker een goede zaak (om later makkelijker bugs te vinden/op te lossen)
het is niet omdat je niet de snelste hoeft te zijn, dat je de traagste wil zijn...
als iets minder tweaken de code "mooier" kan houden, lijkt mij dat zeker een goede zaak (om later makkelijker bugs te vinden/op te lossen)
Heel goed, snel bugs kunnen vinden lijkt mij voor IE het belangrijkste doel...
Klopt, maar tussen "de snelste willen zijn" en "belachelijk traag zijn" zitten nog behoorlijk wat tussenstappen.
http://www.opera.com/docs/changelogs/windows/1010/
hier vind je ongetwijfeld jouw antwoord in.
hier vind je ongetwijfeld jouw antwoord in.
Omdat ze om een of andere vage reden gekozen hebben om 10.10 en 10.5 te schrijven ipv 10.10 en 10.50, of 10.1 en 10.5.
10.50 is de nieuwste versie en deze had, net als IE9 tov IE8, als een van de speerpunten de sterk versnelde javascript engine.
10.50 is de nieuwste versie en deze had, net als IE9 tov IE8, als een van de speerpunten de sterk versnelde javascript engine.
Tussen 10.10 en 10.50 is de javascript engine opnieuw geïmplementeerd.
Ik denk dat 10.5 de nieuwste is en 10.10 de oudste ook al lijken die nummers vertekend, maar in digitaal is het 10.1/10.5 volgens mij, en dan is 10.5 dus hoger als 10.10 of 10.1000000000000
haha mod-systeem blijft me verbazen
haha mod-systeem blijft me verbazen
[Reactie gewijzigd door watercoolertje op woensdag 17 maart 2010 14:33]
Klopt. Ze zijn in de tabel niet consequent wat verwarring oplevert. Ze plakken wel de 0 achter 10.1 maar niet achter 10.5. Het zou simpelweg Opera 10.10 en Opera 10.50 moeten zijn -- zo doet Opera het zelf. 10.50 is inderdaad nieuwer.
Dit doen ze omdat ze ook bugfix releases maken. Zo komt binnenkort al Opera 10.51 op Windows.
Dan zou een 10.5.0 meer op zijn plek zijn.
Ontopic: Mooi dat Microsoft nu toch echt wat probeert te doen aan IE. Zal menig webdeveloper blij mee zijn.
Ik blijf bij Firefox/Chrome.
Ontopic: Mooi dat Microsoft nu toch echt wat probeert te doen aan IE. Zal menig webdeveloper blij mee zijn.
Ik blijf bij Firefox/Chrome.
Dat doen ze toch altijd al bij opera, ze gebruiken dit soort getallen al jaren. Opera 7.54, Opera 8.53, Opera 8.54
9.51 9.52 zijn ook al een tijdje in omloop, niks raars aan. En bij mijn komt 10.1 nog altijd voor 10.5. Ze hebben je als het goed is op school geleerd dat een nul achter een getal achter de komma niks waard is en net zo goed weggehaald kan worden.
9.51 9.52 zijn ook al een tijdje in omloop, niks raars aan. En bij mijn komt 10.1 nog altijd voor 10.5. Ze hebben je als het goed is op school geleerd dat een nul achter een getal achter de komma niks waard is en net zo goed weggehaald kan worden.
[Reactie gewijzigd door mad_max234 op woensdag 17 maart 2010 13:16]
Goed om te weten dat hier meestal de . geen decimaal aangeeft maar een scheidingsteken is.9.51 9.52 zijn ook al een tijdje in omloop, niks raars aan. En bij mijn komt 10.1 nog altijd voor 10.5. Ze hebben je als het goed is op school geleerd dat een nul achter een getal achter de komma niks waard is en net zo goed weggehaald kan worden.
10.1 is dus versie 10 subversie 1
10.10 is dus versie 10 subversie 10
Oftewel 10.1 is iets anders dan 10.10.
Hoe ze dat in dit specifieke geval doen weet ik niet, maar het zou me verbazen als het anders was.
Ik gebruik voor mijn eigen software meestal x.x.x maar er is geen officiële manier zover ik weet, wel is er een officieel afspraak in ons rekenen die zegt dat 0.10 het zelfde is als 0.1
En we hebben ook afgesproken dat de komma het decimaalscheidingsteken is en bovendien kan in een getal maar één decimaalscheidingsteken zitten.
Nee, hoor. Afgesproken is dat
0.10 tussen de 0.095 en de 0.105 zit of wel [0.095,0.105>
0.1 tussen de 0.05 en de 0.15 zit [0.05,0.15>
0.10 tussen de 0.095 en de 0.105 zit of wel [0.095,0.105>
0.1 tussen de 0.05 en de 0.15 zit [0.05,0.15>
Versies zijn dan ook geen getallen. Er bestaat zelfs geen algemeen aangeleerde vorm van versienummer. Ene doet 1.01, 1.02, 1.03, ... en andere doet 1.1, 1.2, 1.3
Geeft pas een probleem vanaf tientallen.
Geeft pas een probleem vanaf tientallen.
Die benchmark zegt niets over praktijkervaring. Is zoals een 128core cpu benchmarken maar vergeten te constateren dat met een dualcore de bottleneck van je applicatie ook al bij je harde schijf zit.
Je gaat geen 7keer sneller surfen door van IE8 naar IE9 over te stappen. Je gaat enkel iets merken op sites waar te veel javascript is gebruikt.
Je gaat geen 7keer sneller surfen door van IE8 naar IE9 over te stappen. Je gaat enkel iets merken op sites waar te veel javascript is gebruikt.
voor oudere computers doet een snellere browser echt wonderen hoor
"waar te veel javascript is gebruikt."
Een snellere browser laat net toe om meer JavaScript te gaan gebruiken. Veronderstellen dat browsers minder JavaScript moeten gebruiken om tegemoet te komen aan oudere browsers is gewoon stilstaan in de tijd...
Een snellere browser laat net toe om meer JavaScript te gaan gebruiken. Veronderstellen dat browsers minder JavaScript moeten gebruiken om tegemoet te komen aan oudere browsers is gewoon stilstaan in de tijd...
Vind het wel begrijpelijk dat het niet onder XP zal werken, veel bedrijven en consumenten zullen trouw aan XP blijven, maar het platform is simpelweg 8 jaar oud, MS kan niet eeuwig nieuwe software voor zoiets ouds ontwikkelen.. ook een kleine promotie voor 7 denk ik
Eigenlijk vind ik het wél raar. Er worden nog steeds veel computers met windows XP verkocht (netbooks) en de install base van windows XP is gigantisch. Immers, Windows Vista was een flop en Win7 is pas net uit.
Maar het is weer niet raar als je bedenkt dat MS van XP af wil. En aangezien IE ook van MS is werkt die keus hier door.Eigenlijk vind ik het wél raar. Er worden nog steeds veel computers met windows XP verkocht (netbooks) en de install base van windows XP is gigantisch. Immers, Windows Vista was een flop en Win7 is pas net uit.
En het is weer wel raar als je bedenkt dat MS elke maand marktaandeel verliest op browsergebied. Aangezien deze browser dus blijkbaar niet eens werkt op bepaalde platforms zullen mensen met oudere platforms over moeten stappen naar een non-IE variant om bij te blijven. Immers, IE6 is uitgerangeerd, IE7 volgt hopelijk snel en ook IE8 is nog niet perfect: de alternatieven renderen pagina's momenteel gewoon beter (zie ook scores van ACID tests) en overstappen is dus niet zo'n heel gekke keuze.
Acid tests zijn allemaal leuk en aardig om mee te patsen, maar betekenen weinig in de praktijk. Echte website worden toch getest of ze goed werken in meerdere browsers, en zullen er in de praktijk overal ongeveer hetzelfde uit zien.
De echte redenen om over te stappen liggen niet zozeer in de rendering engine, maar gewoon in een bepaald idee wat iemand over een browser heeft. De meeste mensen die IE hebben gedumpt hebben dat niet gedaan omdat firefox zoveel betere scoorde in de acid test, maar omdat het veiliger is, of de GUI handiger vinden, of een hekel hebben aan MS, of bepaalde features nodig hebben, of, of, of...
De echte redenen om over te stappen liggen niet zozeer in de rendering engine, maar gewoon in een bepaald idee wat iemand over een browser heeft. De meeste mensen die IE hebben gedumpt hebben dat niet gedaan omdat firefox zoveel betere scoorde in de acid test, maar omdat het veiliger is, of de GUI handiger vinden, of een hekel hebben aan MS, of bepaalde features nodig hebben, of, of, of...
Een heleboel (professional- en amateur-) webontwikkelaars hebben IE JUIST om die reden gedumpt.
Ik ben het met je eens dat een 100% score op een acid test lang niet alles zegt en ook niet noodzakelijk is voor een goeie browser, maar het is toch wel een nobel streven. En wat zien we bij IE? In een tijd dat Acid-3 door alle moderne browsers eigenlijk een jaar geleden al als een gepasseerd stadium werd beschouwt met scores van 90+%, komt microsoft nu met een schamele 55%. Wat mij betreft een teken dat we IE nog steeds niet serieus kunnen nemen w.b.t. implementatie van webstandaarden.
Ik ben het met je eens dat een 100% score op een acid test lang niet alles zegt en ook niet noodzakelijk is voor een goeie browser, maar het is toch wel een nobel streven. En wat zien we bij IE? In een tijd dat Acid-3 door alle moderne browsers eigenlijk een jaar geleden al als een gepasseerd stadium werd beschouwt met scores van 90+%, komt microsoft nu met een schamele 55%. Wat mij betreft een teken dat we IE nog steeds niet serieus kunnen nemen w.b.t. implementatie van webstandaarden.
Check deze tabel: http://samples.msdn.microsoft.com/ietestcenter/
De non-IE browsers hebben nog veel werk te doen!
De non-IE browsers hebben nog veel werk te doen!
De tests zijn samen met het W3C opgezet en je kunt de cases stuk voor stuk zelf testen. Zag hieronder al een link met een paar voorbeelden die voor meerdere interpretaties vatbaar zijn, maar voor de rest moeten de browservendors opschieten (zet maar eens wat druk op het W3C met het uitblijven van een definitive CSS3/HTML5 spec).Het is wellicht zo, maar ik geloof het pas als een onafhankelijke bron het zegt.
[Reactie gewijzigd door Rick2910 op woensdag 17 maart 2010 18:19]
Je beseft wel dat dat artikel een hoog "wij van WC eend adviseren... WC eend" gehalte heeft, toch? Ik bedoel, een MS artikel dat IE9 beter doet lijken dan de concurrentie. Het is wellicht zo, maar ik geloof het pas als een onafhankelijke bron het zegt.
(reactie op Rick2910)
(reactie op Rick2910)
[Reactie gewijzigd door Robtimus op woensdag 17 maart 2010 18:01]
Vista is al 4jaar uit en heeft ondertussen zelfs al 2SP's achter de rug. Bedrijven kunnen gewoon voor Vista gaan en de overstap naar Win7 zal véél makkelijker gaan.
Vista is mislukt, ook al draait het nu wel stabiel, de naam heeft het en zal het houden. Zelfde als ME. Voor de gebruiker is het maar 1 OS verschil en dat is te weinig. Ik blijf wel bij FF die werkt over al op.
Denk dat bijna iedere systeembeheerder bij welk bedrijf dan ook je uit zal lachen als je nu met Vista aan komt zetten. Het is niet alleen veroudert (win7 is de laatste versie), het heeft ook een slechte naam. Je moet wel heel erg weinig van IT weten om in 2010 nog Vista bakken uit te willen rollen.
Je moet wel heel erg weinig van IT weten om te denken/verkondigen dat er iets mis is met Vista.
Een slechte naam is nou niet bepaald een criterium waar een systeembeheerder zich iets van aan hoeft te trekken.
Een slechte naam is nou niet bepaald een criterium waar een systeembeheerder zich iets van aan hoeft te trekken.
Meestal is het niet de systeembeheerder die beslist over budgetten, als Vista bij het management een slechte naam heeft komt het er echt niet in.
Misschien valt dit ook onder het initiatief om alternatieve browsers te promoten
Aan de andere kant werken Mozilla Firefox, Google Chrome en Apple Safari nog wel onder MS-Windows XP. Ik zie dus ook niet in waarom MSIE9 in eens niet meer onder XP zou kunnen werken.
Natuurlijk werken alle veiligheidsopties dan niet, maar een groot probleem hoeft dat ook weer niet te zijn... Als ze nu onder MSIE8 ook al niet werken mist de XP-gebruiker niets namelijk....
Natuurlijk werken alle veiligheidsopties dan niet, maar een groot probleem hoeft dat ook weer niet te zijn... Als ze nu onder MSIE8 ook al niet werken mist de XP-gebruiker niets namelijk....
Mozilla, Google, Apple en Opera hoeven Windows Vista / 7 niet te verkopen. MS wel.
Mogelijk omdat er API's gebruikt worden die op XP niet voorkomen voor bijvoorbeeld de hardwareversnelling.Ik zie dus ook niet in waarom MSIE9 in eens niet meer onder XP zou kunnen werken
Men zou natuurlijk ook gewoon een versie voor XP kunnen maken, maar blijkbaar is dat te moeilijk?
De andere grote browserbouwers krijgen het echter wel voor elkaar en ondersteunen soms zelfs nog MS-Windows 2000 - iets dat MSIE7+ ook al niet doet...
De andere grote browserbouwers krijgen het echter wel voor elkaar en ondersteunen soms zelfs nog MS-Windows 2000 - iets dat MSIE7+ ook al niet doet...
Maar waarom zouden ze de moeite doen voor een OS wat officieel allang al end-of-life is? Dat anderen nog XP ondersteunen is hun eigen keuze. Of waarschijnlijk is het niet zozeer een keuze, maar een gevolg uit het feit dat de rest op meerdere platformen draait, en dus sowieso al een stuk meer portable is. MS kennende zullen ze IE9 wel vol proppen met windows-only dingen die er pas sinds Vista in zitten...
Volgens mij ondersteunt geen ene grote win2k meer, iig Firefox en Safari niet. Firefox is meen ik me te herinneren met enkele workarounds wel aan de praat te krijgen.
Maar dus geen officiële ondersteuning
Maar dus geen officiële ondersteuning
[Reactie gewijzigd door Xthemes.us op donderdag 18 maart 2010 01:09]
Omdat MS anders ondersteuning moet gaan inbouwen voor OS'en die bvb. geen Direct2D en DirectWrite ondersteunen, waardoor de code ingewikkelder wordt en moeilijker om te testen.
ff aanvullen
en dat het bijgevolg langer duurt om ie9 te omwikkelen en we bijgevolg nog langer met IE6/7/8 opgescheept zitten?
en dat het bijgevolg langer duurt om ie9 te omwikkelen en we bijgevolg nog langer met IE6/7/8 opgescheept zitten?
[Reactie gewijzigd door masterpoi op woensdag 17 maart 2010 13:32]
Yup, en Xp zit al in de extended supportfase. Denk niet dat er ook nog een nieuwe WMP voor zal komen.
Dat zal niet de reden zijn, er is gewoon iets nodig wat pas vanaf vista SP2 aanwezig is, zelfs vista en vista met SP1 zullen niet ondersteunt worden.
XP en ook vista zonder sp2 is gewoon niet geschikt voor IE9 te draaien op de manier zoals MS dat wilt, zal vast wel een hack voor te maken zijn, wellicht dat sommige functie dan niet werken van IE9.
Ondersteuning van XP loopt nog gewoon tot april 2014, microsoft heeft xp nog niet afgeschreven. (weet niet of dat volledig ondersteuning is)
Edit/
http://www.microsoft.com/...indowsxp/future_prod.mspx
XP en ook vista zonder sp2 is gewoon niet geschikt voor IE9 te draaien op de manier zoals MS dat wilt, zal vast wel een hack voor te maken zijn, wellicht dat sommige functie dan niet werken van IE9.
Ondersteuning van XP loopt nog gewoon tot april 2014, microsoft heeft xp nog niet afgeschreven.
(weet niet of dat volledig ondersteuning is)Edit/
http://www.microsoft.com/...indowsxp/future_prod.mspx
[Reactie gewijzigd door mad_max234 op woensdag 17 maart 2010 13:07]
Dat is dus de extended support. Maw. geen nieuwe features van MS, alleen hotfixes ed.
Dat is de extended support fase. Daarin worden nog wel security patches doorgevoerd maar geen upgrades meer.Ondersteuning van XP loopt nog gewoon tot april 2014
[Reactie gewijzigd door hAl op woensdag 17 maart 2010 13:23]
Zorgt er wel voor dat we dus straks een nieuwe bottleneck krijgen voor developers namelijk IE8 in combi met Windows XP en je klanten laten upgraden naar een nieuwe IE versie gaat toch wat makkelijker dan naar een geheel nieuw OS.
Volgens mij was het trouwens nog niet duidelijk of de uiteindelijke versie op Windows XP zal draaien, alleen dat de huidige preview niet hierop draaiden vanwege enkele nieuwe features, zie ook de FAQ
http://ie.microsoft.com/t...kedQuestions/Default.html
Ik ben verder wel onwijs benieuwd naar de uiteindelijke IE9 ze hebben al een hoop erin zitten en rechtgetrokken ten opzichte van alternatieve browsers qua standards / features en snelheid.
Zit alleen nog met het hele HTML5 video codec gebeuren in me maag,
hopelijk zullen ze echter nog wel support inbouwen voor OGG als codec of dat Google een beetje opschiet met het publiek maken van de ON2, want dan komt een goeie bruikbare flash video alternatief zeer dichtbij :-)
Wat zeker is dat ze bij Microsoft i.i.g. weer een flinke stap voorruit aan het maken zijn.
Volgens mij was het trouwens nog niet duidelijk of de uiteindelijke versie op Windows XP zal draaien, alleen dat de huidige preview niet hierop draaiden vanwege enkele nieuwe features, zie ook de FAQ
http://ie.microsoft.com/t...kedQuestions/Default.html
Ik ben verder wel onwijs benieuwd naar de uiteindelijke IE9 ze hebben al een hoop erin zitten en rechtgetrokken ten opzichte van alternatieve browsers qua standards / features en snelheid.
Zit alleen nog met het hele HTML5 video codec gebeuren in me maag,
hopelijk zullen ze echter nog wel support inbouwen voor OGG als codec of dat Google een beetje opschiet met het publiek maken van de ON2, want dan komt een goeie bruikbare flash video alternatief zeer dichtbij :-)
Wat zeker is dat ze bij Microsoft i.i.g. weer een flinke stap voorruit aan het maken zijn.
Alleen dat laatste zul je bedoelen. Overigens heb ik er geen enkel probleem mee dat ze XP niet ondersteunen, Firefox, chrome, Opera doen het wel en dat zijn veel betere browsers dan de Internet Explorer ooit zal worden.
MS hinkt namelijk op twee benen. Aan de ene kant willen ze juist niet dat de browser een snel platform wordt voor netapplicaties en aan de andere kant willen ze ook niet weg geconcurreerd worden op de browsermarkt. Dat IE zo traag was, lijkt dan ook een bewuste keuze. Want zolang mensen nog overwegend met IE werken (zeker in bedrijven), heeft dat een ongunstige uitwerking op het gebruik van netapplicaties.
Maar nu mensen massaal beginnen te ontdekken dat er andere en ook betere browsers zijn dan IE willen ze toch de in het oog lopende verschillen kleiner maken. Maar ik reken erop dat ze beperkingen zullen handhaven omdat hun belang nu eenmaal niet is dat netapplicaties een grote vlucht nemen. Het zal mij ook niet verbazen dat bepaalde concurrerende Netapplicaties in IE niet zo lekker zullen draaien, maar dat hij wel geoptimaliseerd wordt voor hun eigen producten.
MS hinkt namelijk op twee benen. Aan de ene kant willen ze juist niet dat de browser een snel platform wordt voor netapplicaties en aan de andere kant willen ze ook niet weg geconcurreerd worden op de browsermarkt. Dat IE zo traag was, lijkt dan ook een bewuste keuze. Want zolang mensen nog overwegend met IE werken (zeker in bedrijven), heeft dat een ongunstige uitwerking op het gebruik van netapplicaties.
Maar nu mensen massaal beginnen te ontdekken dat er andere en ook betere browsers zijn dan IE willen ze toch de in het oog lopende verschillen kleiner maken. Maar ik reken erop dat ze beperkingen zullen handhaven omdat hun belang nu eenmaal niet is dat netapplicaties een grote vlucht nemen. Het zal mij ook niet verbazen dat bepaalde concurrerende Netapplicaties in IE niet zo lekker zullen draaien, maar dat hij wel geoptimaliseerd wordt voor hun eigen producten.
[Reactie gewijzigd door degener op woensdag 17 maart 2010 13:48]
Wat een ongegronde uitlating tov MS zeg...
Microsoft heeft absoluut zijn browser niet opzettelijk traag gemaakt! Microsoft had gewoon last van een on-concurrentiële markt na IE6! Ze hadden de hele browser markt in handen voor vele jaren, en investeren hierin was het laatste waar ze blijkbaar aan dachten.
Dus konden kleine browsers wel gaan innoveren en een grote voorsprong nemen op Internet Explorer
Het internet is ook sterk veranderd sinds IE6 en javascript/Css/SVG toestanden vernieuwen het web, maar creëren ook de nood aan andere browser technologieën.
Daarom zie je ook dat elke browser bouwer wel een volledige herschrijving van hun javascript en rendering gedaan heeft.
Microsoft had niet alleen die achterstand als probleem, maar ook nog eens de compatibiliteit met hun oude versies! Ze kunnen het hun niet veroorloven dat al de sites die speciaal aangepast zijn voor op hun oude browser te werken nu in hun nieuwste versie het niet meer behoorlijk zouden doen.
Microsoft is helemaal niet bang van webapps ze hebben er zelf al cloud diensten, online mail, online office, .... en ze behoren nog eens bij de top van hun categorieën ook
Explorer zal nooit 'beter' worden dan Chrome? ik ziet absoluut niet in waarom, ik heb geen glazen bol om zo een wilde voorspellingen te doen. Maar ik zie het eerder wel gebeuren dan niet
Microsoft heeft absoluut zijn browser niet opzettelijk traag gemaakt! Microsoft had gewoon last van een on-concurrentiële markt na IE6! Ze hadden de hele browser markt in handen voor vele jaren, en investeren hierin was het laatste waar ze blijkbaar aan dachten.
Dus konden kleine browsers wel gaan innoveren en een grote voorsprong nemen op Internet Explorer
Het internet is ook sterk veranderd sinds IE6 en javascript/Css/SVG toestanden vernieuwen het web, maar creëren ook de nood aan andere browser technologieën.
Daarom zie je ook dat elke browser bouwer wel een volledige herschrijving van hun javascript en rendering gedaan heeft.
Microsoft had niet alleen die achterstand als probleem, maar ook nog eens de compatibiliteit met hun oude versies! Ze kunnen het hun niet veroorloven dat al de sites die speciaal aangepast zijn voor op hun oude browser te werken nu in hun nieuwste versie het niet meer behoorlijk zouden doen.
Microsoft is helemaal niet bang van webapps ze hebben er zelf al cloud diensten, online mail, online office, .... en ze behoren nog eens bij de top van hun categorieën ook
Explorer zal nooit 'beter' worden dan Chrome? ik ziet absoluut niet in waarom, ik heb geen glazen bol om zo een wilde voorspellingen te doen. Maar ik zie het eerder wel gebeuren dan niet
Allereerst is het pas sinds Netscape bloated werd en wat problemen kreeg dat IE het merendeel van de markt in handen heeft. Zal zo rond de millennium wisseling geweest zijn.
En Microsoft heeft zich wel heel bewust verzet tegen de standaarden. HTML 4.0 en CSS2 waren ruim anderhalf jaar voor IE5 (wat je als de eerste populaire IE versie mag beschouwen) al gespecificeerd; tot op de dag van vandaag rendert geen enkele IE versie deze twee correct. Verbeter me maar als het niet zo is, maar 5/6 hebben sowieso het box-model probleem, en voor zover ik weet is ook het boxmodel van IE7 nog steeds niet in orde. En dat is maar het topje van de ijsberg. Ik heb de afgelopen twee jaar vrijwel niets met CSS hoeven doen omdat ik daar collega's voor heb, maar ik heb me dood geërgerd aan IE toen ik er wel nog veel mee werkte.
Overigens heb ik het over de W3C recommendations; de drafts zijn dus nog ouder. Het is niet alsof MS geen tijd had om zich aan te passen.
Compatabiliteit met oudere versies? Zelfs simpele sites hadden toentertijd over het algemeen een apart stylesheet voor IE, en een ander voor fatsoenlijke browsers, dus dat probleem waar jij het over hebt bestaat eigenlijk niet. JS en CSS zijn ook veel ouder dan jij denkt, en zoals ik zei, is het MS die anders is t.o.v. de rest en gewoon nooit mee heeft gewerkt aan de standaarden.
En ja, fijn die webapps. Maar wederom maken die gebruik van IE-specifieke functies, terwijl dezelfde functionaliteit ook met algemene functionaliteit kan. Voorbeeldje hebben? Bekijk MS Exchange webmail eens in een andere browser dan IE, en bekijk dan de gemiddelde webapp in diezelfde browser. Waarom moet MS Exchange er zo slecht uitzien in een non-IE browser?
Begrijp me niet verkeerd, niet alles wat MS doet is verkeerd (Windows 7 is heerlijk) - maar als webdeveloper is het moeilijk om geen hekel te hebben aan IE, vooral als je dan ziet hoe MS opschept over dingen als Silverlight. Tegelijkertijd hebben ze 12 jaar na HTML 4.0/CSS2 nog steeds geen vlekkeloze implementatie daarvan.
Ze hebben geen achterstand opgelopen, die hebben ze zelf gecreëerd.
En Microsoft heeft zich wel heel bewust verzet tegen de standaarden. HTML 4.0 en CSS2 waren ruim anderhalf jaar voor IE5 (wat je als de eerste populaire IE versie mag beschouwen) al gespecificeerd; tot op de dag van vandaag rendert geen enkele IE versie deze twee correct. Verbeter me maar als het niet zo is, maar 5/6 hebben sowieso het box-model probleem, en voor zover ik weet is ook het boxmodel van IE7 nog steeds niet in orde. En dat is maar het topje van de ijsberg. Ik heb de afgelopen twee jaar vrijwel niets met CSS hoeven doen omdat ik daar collega's voor heb, maar ik heb me dood geërgerd aan IE toen ik er wel nog veel mee werkte.
Overigens heb ik het over de W3C recommendations; de drafts zijn dus nog ouder. Het is niet alsof MS geen tijd had om zich aan te passen.
Compatabiliteit met oudere versies? Zelfs simpele sites hadden toentertijd over het algemeen een apart stylesheet voor IE, en een ander voor fatsoenlijke browsers, dus dat probleem waar jij het over hebt bestaat eigenlijk niet. JS en CSS zijn ook veel ouder dan jij denkt, en zoals ik zei, is het MS die anders is t.o.v. de rest en gewoon nooit mee heeft gewerkt aan de standaarden.
En ja, fijn die webapps. Maar wederom maken die gebruik van IE-specifieke functies, terwijl dezelfde functionaliteit ook met algemene functionaliteit kan. Voorbeeldje hebben? Bekijk MS Exchange webmail eens in een andere browser dan IE, en bekijk dan de gemiddelde webapp in diezelfde browser. Waarom moet MS Exchange er zo slecht uitzien in een non-IE browser?
Begrijp me niet verkeerd, niet alles wat MS doet is verkeerd (Windows 7 is heerlijk) - maar als webdeveloper is het moeilijk om geen hekel te hebben aan IE, vooral als je dan ziet hoe MS opschept over dingen als Silverlight. Tegelijkertijd hebben ze 12 jaar na HTML 4.0/CSS2 nog steeds geen vlekkeloze implementatie daarvan.
Ze hebben geen achterstand opgelopen, die hebben ze zelf gecreëerd.
[Reactie gewijzigd door Werelds op woensdag 17 maart 2010 15:00]
In den beginne hoopten ze hun eigen VBscript te kunnen pushen i.p.v. Javascript. Ze ondersteunden wel Jscript maar dat was in het begin heel beperkt. Volgens mij waren ze net te laat actief op Internet om er hun stempel op te drukken.
Gelukkig maar.
Gelukkig maar.
on-concurrentiële markt?Microsoft had gewoon last van een on-concurrentiële markt na IE6!
We noemen dat een monopoliepositie en Microsoft heeft daar geen "last" van
Wij consumenten hebben daar last van
[Reactie gewijzigd door degener op woensdag 17 maart 2010 23:35]
Zeker wel, als de dood zelfs. Als u dat niet gelooft doet u er goed aan de 'internet tidal wave' memo van Bill Gates eens te lezen.Microsoft is helemaal niet bang van webapps
Documentje uit het vorige milennium (1995), dat wel, maar beschrijft heel goed hoe bang Bill Gates is dat Microsoft software op het internet niet meer nodig is en Microsoft daarom irrelevant wordt.
Dat is dus 15 jaar oud. Ook bij Microsoft is er wel wat veranderd.
Dit is wel heel erg hardware-gebonden. IE9 maakt gebruik van meer (ongebruikt) rekenvermogen van de computer. Met een single core en IGP heb je met IE9 nog steeds een schildpad, zo lijkt het. Het komt niet echt neer op slimmer "hardware-onafhankelijk" programmeren.Internet Explorer 9 gebruikt bij multicoresystemen namelijk een aparte processorcore om javascript te vertalen. Microsoft claimt dat het Chakra in de komende tijd nog sneller kan maken. Verder gebruikt IE9 de videokaart om het renderen van html5-video en vectorgraphics te versnellen.
Hoe doen Chrome en Opera dit?
Single core? Is dat nog van deze tijd? Ik vind het dus zeer zeker wel een slimme zet door andere cores te gebruiken.
En wat betreft Opera heb ik geen idee, maar Chrome maakt voor iedere "tab" een eigen process aan welk ieder draaien op een willekeurige core. Of Chrome daarnaast voor zaken als JS ook nog een aparte core gebruikt of per process binnen die core laat draaien weet ik niet, maar in ieder geval maakt Chrome goed gebruik van multi-core functionaliteit.
In mijn ogen is het in de tijd van quad cores, en soon to be hexacores, bijzonder inefficient om daar niet op gericht te programmeren.
En wat betreft Opera heb ik geen idee, maar Chrome maakt voor iedere "tab" een eigen process aan welk ieder draaien op een willekeurige core. Of Chrome daarnaast voor zaken als JS ook nog een aparte core gebruikt of per process binnen die core laat draaien weet ik niet, maar in ieder geval maakt Chrome goed gebruik van multi-core functionaliteit.
In mijn ogen is het in de tijd van quad cores, en soon to be hexacores, bijzonder inefficient om daar niet op gericht te programmeren.
Wat dacht je van de mobiele versie of van netbooks?Single core? Is dat nog van deze tijd? Ik vind het dus zeer zeker wel een slimme zet door andere cores te gebruiken.
Wat je eigenlijk wilt is dat de software een nieuw proces start en dat het systeem bepaalt waarop die draait. Uiteraard met een goede load-balancing door het systeem. Het systeem bepaalt dan of alles op 1 of meerdere processoren draait. En in het geval je er maar 1 hebt starten ze allemaal op dezelfde..
Dit is wat volgens mijn indruk ook gebeurd.
[Reactie gewijzigd door ritsjoena op woensdag 17 maart 2010 13:03]
Moderne netbooks worden steeds vaker multicore, zodra IE9 officieel uit is zullen singlecore netbooks waarschijnlijk niet langer van deze tijd zijn.
En wat je verder beschrijft is precies wat met zo goed als 99.9% van alle software gebeurd, de applicatie maakt gewoon nieuwe processes of gebruikt meerdere threads en laat het verder aan het OS over waar dit draait. Er zijn slechts specifieke uitzonderingen waarin de programmeur ervoor kiest om iets op core 1 te draaien en een ander deel op core 2 bijvoorbeeld.
Dus, blijft het toch inefficient om daar niet naar te programmeren?
En wat je verder beschrijft is precies wat met zo goed als 99.9% van alle software gebeurd, de applicatie maakt gewoon nieuwe processes of gebruikt meerdere threads en laat het verder aan het OS over waar dit draait. Er zijn slechts specifieke uitzonderingen waarin de programmeur ervoor kiest om iets op core 1 te draaien en een ander deel op core 2 bijvoorbeeld.
Dus, blijft het toch inefficient om daar niet naar te programmeren?
Wat?Moderne netbooks worden steeds vaker multicore, zodra IE9 officieel uit is zullen singlecore netbooks waarschijnlijk niet langer van deze tijd zijn.
Filter de pricewatch maar eens op Atom N330/N550:
Daarvan heeft 1 de prijs van een whopping 2160 Euro, en de overige is de 1201N in twee kleurstellingen. Dus zo "steeds vaker" vind ik het allemaal niet.
[Reactie gewijzigd door SirNobax op woensdag 17 maart 2010 13:22]
Wat is je punt eigenlijk? Dat IE9 geen multi-core ondersteuning moet krijgen zolang er single-core cpu's zijn?
Dat een van de posters hierboven onzin blaat door een opmerking in de trant van "Single core wtf lolololol!" te posten, lijkt mij. Leuk voor hem dat hij alleen maar moderne machines heeft, daar is ie een tweaker voor, maar een hoop mensen hebben nog oude bakkies staan, gewoon omdat ze het nog doen en er dus geen reden is om ze te vervangen. Een nieuwe browser lijkt me voor het grootste deel van die mensen geen goede reden om naar de winkel te rennen.
Je threads op andere cores forceren is juist niet efficiënt. Idle kan je namelijk per core downclocken en dus veel stroom besparen.
Liever 50% belasting op een core dan 25% belasting over twee cores.
Die dingen moet je aan het OS overlaten ipv in je programma te schrijven.
Liever 50% belasting op een core dan 25% belasting over twee cores.
Die dingen moet je aan het OS overlaten ipv in je programma te schrijven.
OS'en zijn zeer slecht in het verdelen van de workload van twee threads over 2 cores. Ze blijven maar van core naar core swappen en dat leverd een veel hogere belasting op.
Ik heb laptops gezien waar biede cores op 70% draaiden door 2 processen. Beide processen vastpinnen op een processor en eentje draaide op 100% en de andere rond de 0%!
Ik heb laptops gezien waar biede cores op 70% draaiden door 2 processen. Beide processen vastpinnen op een processor en eentje draaide op 100% en de andere rond de 0%!
Volgens mij heb je het dan niet over "OS'en" in het algemeen, maar over Windows, en wss XP. Heb onder Linux nog nooit iets raars gezien met meerdere cores...
En een fout in je OS opvangen door je applicatie minder efficient te maken is natuurlijk de oplossing niet he. Als het een fout in het OS is, moet het OS gerepareerd worden.
En een fout in je OS opvangen door je applicatie minder efficient te maken is natuurlijk de oplossing niet he. Als het een fout in het OS is, moet het OS gerepareerd worden.
daar moet je zwaar mee opletten, het kan best zijn dat beide threads op een core goed werkt met beide cores op bv 800MHz en beide threads samen op een core 1600MHz nodig heeft
het is dat helemaal niet zeker dat 2x800 minder verbruikt dan 1x1600 (het verband stroomverbruik-kloksnelheid is namelijk niet lineair)
MS heeft gewoon al het mogelijke in een aparte thread geplaatst, ik denk dat dit perfect past in de huidige filosofie
het is dat helemaal niet zeker dat 2x800 minder verbruikt dan 1x1600 (het verband stroomverbruik-kloksnelheid is namelijk niet lineair)
MS heeft gewoon al het mogelijke in een aparte thread geplaatst, ik denk dat dit perfect past in de huidige filosofie
Onder tweakers, nerds en serieuze gamers zal het zeker niet van deze tijd zijn om een singlecore te hebben, maar er is ook nog zoiets als 'de rest van de wereld'. Laat die laatste groep nou iets van 90% van de computergebruikers wereldwijd zijnSingle core? Is dat nog van deze tijd? Ik vind het dus zeer zeker wel een slimme zet door andere cores te gebruiken.
De meeste Vista en Windows 7 gebruikers zullen wel degelijke een dual core of beter hebben.
Het is toch juist ideaal als er dit soort optimalisaties inzitten. Het meerendeel van de pcs die nu verkocht worden hebben een multicore cpu, dan is het toch mooi als de meest gebruikte browser daar gebruik van maakt.
Ook IGPs hebben prima mogelijkheden om hardwareacceleratie toe te passen (Veel IGPtjes kunnen bijvoorbeeld prima HDcontent accelereren, dus als ze dat ook kunnen doen met de HTML5video, waarom niet).
Natuurlijk zijn er altijd systemen waarbij het niet zo snel zal draaien, maar omdat een klein deel van de markt bestaat uit systemen die hier niet mee overweg kunnen zouden ze dit soort dingen niet toe moeten passen? Ik juig dit juist alleen maar toe.
Ook IGPs hebben prima mogelijkheden om hardwareacceleratie toe te passen (Veel IGPtjes kunnen bijvoorbeeld prima HDcontent accelereren, dus als ze dat ook kunnen doen met de HTML5video, waarom niet).
Natuurlijk zijn er altijd systemen waarbij het niet zo snel zal draaien, maar omdat een klein deel van de markt bestaat uit systemen die hier niet mee overweg kunnen zouden ze dit soort dingen niet toe moeten passen? Ik juig dit juist alleen maar toe.
Hoe kan je HTML5 opnoemen als dat enkel een draft is, als de uiteindelijke HTML5 videocodec heel anders is/wordt dan nu nog in de draft staat werkt die hier niet op hoor
Het gaat dus om de HTML5 Draft, HTML5 bestaat nog niet
Het gaat dus om de HTML5 Draft, HTML5 bestaat nog niet
Sterker nog: HTML5 schrijft geen codec voor.
MS kiest blijkbaar voor H.264 ipv voor de licentievrije Ogg Theora codec. Heel jammer...
MS kiest blijkbaar voor H.264 ipv voor de licentievrije Ogg Theora codec. Heel jammer...
Niet echt. Ogg Theora is qua videokwaliteit (wat imo belangrijker is dan het al dan niet licentievrij zijn) nogal ruk in vergelijking met H.264. Tevens heeft H.264 nogal wat meer voeten aan de grond dan Theora.
Ja idd,
Ogg is vreselijk lelijk en vele malen groter dan een zelfde filmpje in h.264
Lul niet zo slap man, kom met daadwerkelijk vergelijkbaar materiaal en uitleg over hoe mensen het zelf kunnen controleren, of stop het verspreiden van FUD.
http://people.xiph.org/~greg/video/ytcompare/comparison.html
Ogg is vreselijk lelijk en vele malen groter dan een zelfde filmpje in h.264
Lul niet zo slap man, kom met daadwerkelijk vergelijkbaar materiaal en uitleg over hoe mensen het zelf kunnen controleren, of stop het verspreiden van FUD.
http://people.xiph.org/~greg/video/ytcompare/comparison.html
Je link is lekker biased en zelfs hier lees ik:
Het is bijgevolg achteruitgang en dus zal het in zijn huidige vorm nooit door de industrie worden opgenomen (jammergenoeg).In the case of the 499kbit/sec H.264 I believe that under careful comparison many people would prefer the H.264 video. However, the difference is not especially great
"nogal ruk in vergelijking met H.264." is inderdaad exact het zelfde als "However, the difference is not especially great"
Waar precies is de link biased? je kunt alle testjes zelf nalopen, en de kwaliteit zelf beoordelen.
Waar precies is de link biased? je kunt alle testjes zelf nalopen, en de kwaliteit zelf beoordelen.
Over dat ruk zijn heb ik geen uitspraak gedaan.
De link begint met xiph.org? Dat is net hetzelfde als een link van microsoft.com die zegt dat VC-1 de beste uitvinding is sinds warm water.
Lees dit eens (onafhankelijke partij), ik sluit me volledig aan bij de conclusie:
http://www.osnews.com/story/19019/Theora-vs.-h.264
De link begint met xiph.org? Dat is net hetzelfde als een link van microsoft.com die zegt dat VC-1 de beste uitvinding is sinds warm water.
Lees dit eens (onafhankelijke partij), ik sluit me volledig aan bij de conclusie:
http://www.osnews.com/story/19019/Theora-vs.-h.264
[Reactie gewijzigd door masterpoi op woensdag 17 maart 2010 13:46]
Een review van 3 jaar geleden... En met de encoders van beide codecs is in de tussentijd niks gebeurt?
Voer de test opnieuw uit en dan weet je het
Maar je kan ook eens naar de links van Korben kijken
Face it, het enige betere aan theora op dit moment zijn de licentievoorwaarden
Maar je kan ook eens naar de links van Korben kijken
Face it, het enige betere aan theora op dit moment zijn de licentievoorwaarden
Daar word de youtube h264 codec vergeleken met ogg theora, de youtube codec is verre van optimaal, ze hadden beter kunnen vergelijken met x264.
Daarnaast is het ogg container formaat nogal crap
Gebruik dan gewoon de matroska container =)
Kan er niet een soort blokkade komen op die flut link die telkens wordt aangehaald om aan te tonen dat theora wel meekan met h.264.
Dat is namelijk onzin.
De op die pagina gemaakte vergelijking is op allerlie punten waardeloos.
Een voorbeeld is dat in de Youtube video de audio veel meer van de bitrate in neemt dan in de Theora video. Daardoor heeft is het theora video deel al direct tien tot twintig procent groter dan het h.264 video deel.
Verder is de keyframe rate in de theoro video belachelijk laag
Dat is namelijk onzin.
De op die pagina gemaakte vergelijking is op allerlie punten waardeloos.
Een voorbeeld is dat in de Youtube video de audio veel meer van de bitrate in neemt dan in de Theora video. Daardoor heeft is het theora video deel al direct tien tot twintig procent groter dan het h.264 video deel.
Verder is de keyframe rate in de theoro video belachelijk laag
Als het gerefereerde artikel niet deugt, is het zinvol als u ergens een artikel plaatst waarom het niet klopt, zodat anderen zich hier hopelijk een zinnig oordeel over kunnen vellen. Uw omschrijving hier is summier en het is jammer dat mogelijk nuttige informatie hier in het Tweakers-forum terechtkomt waar weinig mensen het lezen.
Destijds ben ik op zoek geweest naar het antwoord van Chris DiBona op het gerefereerde artikel, maar zover ik kon vinden heeft Google nog geen antwoord op deze kwaliteits-vergelijking gegeven.
Destijds ben ik op zoek geweest naar het antwoord van Chris DiBona op het gerefereerde artikel, maar zover ik kon vinden heeft Google nog geen antwoord op deze kwaliteits-vergelijking gegeven.
Er zijn op zat plaatsen commentaren over dat betreffende artikel te vinden.
Ook zat vergelijkingen die het tegendeel aantonen.
Bovendien noem ik al twee heel duidelijke punten waarop het artikel van Xiph enorm faalt.
Het gebruik van verschillende audio codecs in de vergeleken files en het gebruik van een excessief slechte keyframe rate in de Theora files.
Een ander bekend kritiekpuntje dat ik nog even zal noemen is dat die pagina ineens op de laagste bitrate een vergelijking maakt van Theora met de een mindere h.263 codec en niet meer met de meest efficiente h.264 codec.
Ook zat vergelijkingen die het tegendeel aantonen.
Bovendien noem ik al twee heel duidelijke punten waarop het artikel van Xiph enorm faalt.
Het gebruik van verschillende audio codecs in de vergeleken files en het gebruik van een excessief slechte keyframe rate in de Theora files.
Een ander bekend kritiekpuntje dat ik nog even zal noemen is dat die pagina ineens op de laagste bitrate een vergelijking maakt van Theora met de een mindere h.263 codec en niet meer met de meest efficiente h.264 codec.
[Reactie gewijzigd door hAl op donderdag 18 maart 2010 15:47]
Ogg Theora vs. H.264: head to head comparisons. Voila. Een link met een vergelijking waaruit blijkt dat zelfs 1 Mbps Theora merkbaar slechter uit de bus komt dan 468 kbps H.264.
Er staat ook een link naar een recentere vergelijking, waar je heel mooi codecs op verschillende bitrates visueel met elkaar kan vergelijken: KeyJ's Blog: Video encoder comparison. Daar komt uit dat Theora op beide geteste bitrates (500 en 1000 kbps) slechter is dan zelfs x264 Baseline Profile.
FUD? Not quite.
Er staat ook een link naar een recentere vergelijking, waar je heel mooi codecs op verschillende bitrates visueel met elkaar kan vergelijken: KeyJ's Blog: Video encoder comparison. Daar komt uit dat Theora op beide geteste bitrates (500 en 1000 kbps) slechter is dan zelfs x264 Baseline Profile.
FUD? Not quite.
voor een open en vrij internet dat werkt op welk apparaat dan ook is licentieloos een flink stuk belangrijker als dat kleine (en waarschijnlijk tijdelijke) verschil in video kwaliteit.
aan die licentie restricties zitten we namelijk jaren vast, en vormt extra drempels bij het maken van browsers en apparaten die op internet kunnen.
aan die licentie restricties zitten we namelijk jaren vast, en vormt extra drempels bij het maken van browsers en apparaten die op internet kunnen.
[Reactie gewijzigd door Countess op woensdag 17 maart 2010 13:30]
Sterker nog, iedereen die over een paar jaar .h264'tjes op internet wil posten op zijn / haar website moet licentiegeld betalen aan MPEG-LA (heb ik begrepen uit een blog van iemand van Mozilla).
Heb je ook nog een wel objectieve bron ?
Ja want ik kom in het wild zoveel meer theora tegen dan h.264 
Verder heb ik ook nog nergens gelezen dat IE9 final enkel H.264 zal ondersteunen. Ik neem immers aan dat ze directshow oid als backend zullen gebruiken
Verder heb ik ook nog nergens gelezen dat IE9 final enkel H.264 zal ondersteunen. Ik neem immers aan dat ze directshow oid als backend zullen gebruiken
Is het uberhaubt nog relevant hoe goed een engine benckmarked (ww) met javascript? Is volledig (lees: correcte) ondersteuning voor CSS en (toekomstige) HTML5 niet belangrijker? (zoals de acid3 test).
javascript word juist steeds belangrijker.
IE9 scoort op de CSS3 selector test 576 passed van de 578. Dus er zit wel degelijk progressie in.
Net getest en ik scooor gewoon de volledige 578/578 op de CSS3 selectors test
Hmm, zouden de IE programmeurs ook eindelijk SVG onder de knie krijgen?
edit: JAA
edit: JAA
[Reactie gewijzigd door snirpsnirp op woensdag 17 maart 2010 15:21]
De Acid3 test is leuk en het is goed wanneer een browser deze haalt. Maar dan wel graag door de standaarden waarvan delen in Acid3 getest worden volledige te implementeren...
Soms lijkt het er echter op dat er alleen gekeken wordt naar het halen van Acid3 en de rest van de standaard wordt gemaksderhalve nog maar even niet geïmplementeerd...
En ja, een snelle afhandeling van JavaScript wordt steeds belangrijker, nu meer en meer webtoepassingen ontstaan (denk hierbij bijvoorbeeld aan Google Documents).
Soms lijkt het er echter op dat er alleen gekeken wordt naar het halen van Acid3 en de rest van de standaard wordt gemaksderhalve nog maar even niet geïmplementeerd...
En ja, een snelle afhandeling van JavaScript wordt steeds belangrijker, nu meer en meer webtoepassingen ontstaan (denk hierbij bijvoorbeeld aan Google Documents).
Acid 3 test de meest onmogelijke situaties. Een goede webdeveloper zorgt ervoor dat die situaties niet voorkomen. De acid 3 test zegt dan ook niets over de weergave van een normale site. Vandaar ook dat veel browsers traag zijn geweest met het "halen" van de Acid tests. Het is geen prioriteit
@Pete: Opera is qua executie van Javascript voorbijgestreefd door Chrome, Safari en de recente optimalisaties in Firefox (qua browsing experience merk je daar weinig van vind ik, Opera blijft snel aanvoelen). Als reactie daarop hebben ze bij Opera ook een nieuwe Javascript engine ontwikkeld en die zit in 10.5.
Het is natuurlijk maar een preview en als zodanig nog erg slank, maar het is supersnel zo. Hoop dat ze dat kunnen vasthouden
Als het goed is heeft het toevoegen van bijvoorbeeld elementen aan de GUI e.d. amper of geen invloed op de snelheid van de Javascript engine
En meteen maar even de tests van MS te debunken:
ie9 heeft 100% score op de zelf gemaakt tests: http://samples.msdn.microsoft.com/ietestcenter/
Maar veel tests zijn raar, of kloppen niet:
http://underdark.nl/dump/ie9-debunk/
ie9 heeft 100% score op de zelf gemaakt tests: http://samples.msdn.microsoft.com/ietestcenter/
Maar veel tests zijn raar, of kloppen niet:
http://underdark.nl/dump/ie9-debunk/
Dit geldt ook voor veel test gemaakt door andere browserbouwers waarop IE faalt
Zo is er onenigheid over of een bij een span met hidden tekst de tekst decoratie (bijvoorbeeld underline) wel getoond moet worden.
Bepaalde browsers verbergen de teksts maar laten de underline of striketrough veigenschap van die tekst zichtbaar en bijvoorbeld IE doet dat niet.
Dat wordt in de CSS specs gewoon slecht gedefinieerd.
Zo is er onenigheid over of een bij een span met hidden tekst de tekst decoratie (bijvoorbeeld underline) wel getoond moet worden.
Bepaalde browsers verbergen de teksts maar laten de underline of striketrough veigenschap van die tekst zichtbaar en bijvoorbeld IE doet dat niet.
Dat wordt in de CSS specs gewoon slecht gedefinieerd.
Dat geef ik inderdaad ook aan in mn tekstjes bij elke test.
Ik vindt alleen dat MS de "foutjes" wel erg raar genoemd heeft. de selector foutjes zijn bijna allemaal geen selector fouten maar gewoon implementatie verschillen omdat de spec niet duidelijk is, of syntax rariteiten.
De laatste tests zijn gewoon invalid en zouden in ie9 ook een javascript error moeten gooien, maar doen dit blijkbaar niet.
Ik vindt alleen dat MS de "foutjes" wel erg raar genoemd heeft. de selector foutjes zijn bijna allemaal geen selector fouten maar gewoon implementatie verschillen omdat de spec niet duidelijk is, of syntax rariteiten.
De laatste tests zijn gewoon invalid en zouden in ie9 ook een javascript error moeten gooien, maar doen dit blijkbaar niet.
Wel jammer dat het niet meer op XP werkt, maar ik kan het wel begrijpen. XP is bijna 10 jaar oud.
Staat ook gewoon in de tekstOok opvallend is dat Internet Explorer 9 niet onder Windows XP zal werken: Vista met Service Pack 2 is het minimum.
Op dit item kan niet meer gereageerd worden.
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
