Hoofdcategorieën
Device Settings

Ontwikkelaar geeft Firefox Direct 2D-versnelling

Door Dimitri Reijerman, woensdag 25 november 2009 10:29, views: 26.553

Microsoft kondigde onlangs aan dat het hardwarematig versnelde rendering via Direct 2D in Internet Explorer 9 wil gebruiken. Een Nederlandse ontwikkelaar heeft de techniek nu ook in een experimentele build van Firefox 3.7 geïntegreerd.

Firefox-logoSoftware-ontwikkelaar Bas Schouten heeft de code van Firefox 3.7 Alpha 1 aangepast en de traditonele gdi-rendering voor de Windows-versie van de browser vervangen door een experimentele Direct 2D-renderengine, die een gedeelte van het renderwerk aan de gpu uitbesteedt. Het opbouwen van grafisch complexe webpagina's zou daarmee sneller kunnen verlopen; vooral technieken als svg-graphics en css-transforms kunnen volgens Schouten profiteren. Een belangrijke voorwaarde is wel dat een pc is uitgerust met een DirectX 10-videokaart; bij DirectX 9-gpu's zou de prestatiewinst aanmerkelijk kleiner zijn.

Uit benchmarks van Schouten zou blijken dat er met de Direct 2D-versnelling op bepaalde websites een aardige tijdswinst geboekt kan worden. Tests die Betanews uitvoerde, laten echter de keerzijde zien: de renderengine van Schouten kan grafisch complexe websites weliswaar sneller verwerken, maar bij eenvoudige pagina's was de experimentele Firefox-build trager dan de Mozilla-versie en Internet Explorer 8. Bovendien zou de Direct 2D-browser nog crashgevoelig zijn en kunnen er rendering-artefacten optreden.

Volgende 10:54 Playlogic ziet verlies toenemen
Vorige 10:04 Nokia brengt smartphone met capacitief touchscreen uit
Advertentie

Reacties

«  1  2  3  »

Dat is mooi, eindelijk werk voor de GPU. Ik heb altijd het idee dat die nooit aan het werk is, zelfs niet bij het photoshoppen. Bij het surfen zie ik dan ook een mooie inzet voor dit apparaat.

Het probleem is dan alleen wel dat je beter geen grafisch complexe websites open kunt laten staan wanneer je iets anders wilt doen met je GPU.

Gewoon andere tab openen google ofzo.

Hoezo? Content buiten beeld == niet redrawen en dus weinig tot geen impact op de performance. Dat doet Windows al automatisch met veel applicaties. Ga maar eens een HD flashfilmpje bekijken op YouTube en minimaliseer je browser maar, je ziet meteen je CPU usage dalen.

Als je Vista of Windows 7 hebt zul je ook zien dat je van minimized windows waarin video wordt afgespeeld je ook geen geanimeerde Aero Peek hebt maar een still. :)

[Reactie gewijzigd door AtleX op woensdag 25 november 2009 10:41]


Als je Vista of Windows 7 hebt zul je ook zien dat je van minimized windows waarin video wordt afgespeeld je ook geen geanimeerde Aero Peek hebt maar een still. :)
Niet per definitie, dat hangt geheel van de applicatie af. Als ik bijvoorbeeld Windows Media Player in Windows 7 minimaliseer, speelt het filmpje gewoon door. Video in een plug-in (Flash of Silverlight, lijkt niet uit te maken) bevriest inderdaad als het venster geminimaliseerd is.

Hetzelfde concept kun je dus ook doortrekken naar applicaties die op andere manieren GPU-versnelling gebruiken (Direct3D). Dat een applicatie buiten beeld is wil niet zeggen dat die applicatie niet nog steeds de GPU aanspreekt om beeld te renderen.

Tuurlijk niet :)

In jouw voorbeeld wordt 't filmpje gewoon afgespeeld zonder dat de film daadwerkelijk wordt "gedrawed".

Dat klopt niet helemaal. Een filmpje wordt afgespeeld via een overlay. Dat kan een hardware overlay zijn of een direct3d (opengl,....) surface waarop het filmpje als texture wordt geplaatst. Die worden overigens al in beide gevallen door je GPU afgehandeld.

Het pompen van grafische data naar de overlay gaat gewoon door als je de media speler minimaliseert, evenals het uitcoderen van de audio en video kanalen. Alleen is de overlay offscreen waardoor hij niet aan de zichtbare buffer wordt toegevoegd.

Waar de GPU de niet getoonde beelden laat (m.a.w. wanneer hij tot de conclusie komt dat de boel niet getoond gaat worden en het dus weggooit) is deels afhankelijk van hardware en driver implementatie.

In chrome/Iron blijft Flash wel gewoon doordraaien en cpu-tijd vreten hoor.

Echt waar? Lijkt me dat je op het moment dat de site geen focus heeft (op een niet zichtbare tab staat) de rendering engine ook niet aan het werk is om de site te tekenen. Dat is toch wel een basis onderdeel van elke grafische enigne: "Als je het niet zien kan teken het dan ook niet".

Kijk naar Google Chrome, als je computer maar traag genoeg is zal je van zelf zien dat op het moment dat je naar een eerder geopende tab gaat je eerst een static image ziet en dan pas het echte render werk. Het is niet meer dan normaal voor een grafische engine en ik kan me niet aan het idee onttrekken dat Microsoft zo iets niet ook gewoon in hun OS gebruiken. Minimaliseer maar eens een 3D game en je kunt het verschil in de GPU belasting makelijk zien door naar de temperatuur van de GPU te kijken of door gewoon heel simpel de koeling van de GPU te horen terug schakelen.

Je zult schrikken van het aantal games dat vrolijk door kachelt op je cpu op het moment dat je alt tab doet.
Dit kan best ook zo zijn met een GPU, ligt er net aan hoe windows hiermee omgaat, maar het is niet per definitie meteen voor alle apps hetzelfde.

maar een game doet meer dan alleen graphics laten zien :{

In Photoshop, CS4 althans, doet de GPU echt wel z'n werk. Neem maar eens een laptop met een IGP en een laptop of desktop met een high-end dedicated GPU en dan merk je het verschil wel. Vooral met grote (A3 en hoger) bestanden.

Op mijn laptop (met Geforce 8400GS) gaat het scrollen door bestanden, of het verplaatsen van lagen binnen een bestand lang niet zo soepel als op mijn desktop met een Geforce 8800GT. Als je dan echter de grafische versnelling afzet, dan is de prestatie nog lager!

Het helpt dus wel degelijk om een fatsoenlijke GPU in je computer te hebben voor Photoshop.

In Photoshop, CS4 althans, doet de GPU echt wel z'n werk. Neem maar eens een laptop met een IGP en een laptop of desktop met een high-end dedicated GPU en dan merk je het verschil wel. Vooral met grote (A3 en hoger) bestanden.
Het makkelijkst zie je het ook al met in en uitzoomen. Op een IGP gaat dat verscrhikkelijk traag, met een dedicated kaart gaat dat best soepel.

Scrollen en ook resizen van plaatjes is iets dat prima door de gpu gedaan kan worden. Ben benieuwd hoe dit gaat uitpakken.

CS4 is ook specifiek gemaakt (eerste beginselen zaten al in CS2 of 3) waarbij de GPU wordt gebruikt voor rekenkracht. Het feit dat dit pakket het specifiek doet, betekent natuurlijk niet dat dit altijd het geval is :)

Dan zul je ineens gaan merken dat ie niet meer genoeg heeft aan de standaard koeling, en dat je daar ook ineens dure coolers op moet gaan zetten om de boel te koelen. :P

Maar weer ontopic:
Jammer dat je met DirectX 9 nauwelijks prestatiewinst hebt. Heel veel mensen werken nog met Windows XP welke geen DirectX 10 ondersteunt dankzij Microsoft :|

En dat de experimentele Direct 2D browser af en toe klapt of minder snel werkt voor gewone pagina's, dat is natuurlijk maar van korte duur. Zolang de community hier mee bezig is, zal dat t.z.t. verbeterd zijn.
Wellicht dat GPU bouwers nu een aanpassing kunnen doen aan hun chipset om betere ondersteuning voor rendering van websites te bieden, als dat nodig is tenminste.

Ik ben trouwens benieuwd wanneer IE9 met een Direct 2D renderer komt. Wordt een beetje gek van al die browserversies die je moet (gaan) ondersteunen op je website. Dan sla ik IE8 ondersteuning over.

[Reactie gewijzigd door Grrmbl op woensdag 25 november 2009 15:24]


Ik ben een beetje skeptisch hier rond. Over heel Firefox namelijk.

Neem nu bijvoorbeeld 3.6 beta 3. Daar hebben ze nog niet eens een fatsoenlijke Aero Peek implementatie voor. En voor de final willen ze het er zelfs helemaal uithalen.

Dus ik weet niet of dit er in gaat blijven.

Als je een product aflevert, dan moet je geen buggy-code maken. In dat geval zijn er 2 opties, de eerste is wachten tot de bugs eruit zijn (dat kan veel tijd kosten - zie bijvoorbeeld de release van Fx3.1 Fx3.5).

Het alternatief is om de feature niet uit te leveren, of default te disabelen. (Eruit gaat'ie niet, via about:config kun je 'm zelf nog steeds aanzetten).

Overigens is Aero Peek zelf ook niet foutvrij, ik heb op diverse andere applicaties dat'ie gewoon niet goed werkt. Dan moet je eerst het venster openen en daarna werk Aero Peek pas weer...

Als je een product aflevert, dan moet je geen buggy-code maken
Als dat de policy bij Mozilla zou zijn geweest dan was ff 3.x en met name 3.5 nooit uitgebracht. Ff mag dan misschien veel marktaandeel vergaren de laatste tijd, maar ff is ook hard op weg om de bedenkelijke eer te verkrijgen om zich de meest instabiele browser te mogen noemen (binnen OSX, Windows XP,Vista en 7, welke dan meestal weer binnen een VM draaien).

! Ter informatie ik draai vrijwel geen plugins, behalve de 'noodzakelijke' zoals flash en firebug. Ik moet er namelijk op ontwikkelen en dan heb ik geen behoefte aan onzinnige plugins. Voor mijn werk, ontwikkel ik ook op (vrijwel) iedere browser en ik heb dus een redelijk beeld van welke browser stabiel is en welke niet en ik laat me niet leiden door emoties richting een bepaalde browser.

[Reactie gewijzigd door HerrPino op woensdag 25 november 2009 13:12]


Ik draai al tijden met Firefox 3.5 en heb qua stabiliteit geen enkel probleem, dus ik vraag me af waar je je mening op baseert?

Verder is het onmogelijk om een 100% bug-vrij product te maken, maar als je vooraf al weet dat iets niet goed werkt moet je het dan toch uitleveren?

Je hebt van die mensen die 200 plugins gebruiken en het dan gek vinden dat FF er instabiel van wordt.

@Snake In de stabiele versie van FF werkt Aero Peak wel.

[Reactie gewijzigd door Stevendefeij op woensdag 25 november 2009 12:08]


Dat is dan erg vreemd, juist daarom draai ik vrijwel geen plugins ... als je flash e.d. al onder plugins wil rekenen.

Overigens zouden plugins binnen FF binnen een sandbox mogen... nee MOETEN draaien... een crappy plugin zou nooit FF zelf plat mogen leggen.

[Reactie gewijzigd door HerrPino op woensdag 25 november 2009 13:05]


Dat is dan erg vreemd, juist daarom draai ik vrijwel geen plugins ... als je flash e.d. al onder plugins wil rekenen.

Overigens zouden plugins binnen FF binnen een sandbox mogen... nee MOETEN draaien... een crappy plugin zou nooit FF zelf plat mogen leggen.
Flash is idd een plugin. Firebug e.d. zijn extensies (volgens de terminologie van Mozilla).

Flash zal binnenkort met Elektrolysis in een sandbox draaien, zoals in Chrome het geval is.
Mocht de plugin crashen, dan blijft de renderer en dergelijk ook draaien. Ook krijgt elke tab een eigen thread.

Dan draai je geen Windows 7? Ik vind het niet lekker werken op Windows 7 x64 dan.

Maar er kan ook een hoop aan Windows 7 liggen want die is een stuk minder stabiel en ook trager dan Windows XP 64 heb ik het idee. Ook Firefox heeft hier last van en soms crasht hij bij mij of kan ik pagina's niet resolven. Open ik dan Google Chrome dan werkt het wel.

Nu even ontopic wat die GPU rendering betreft. Is het niet mogelijk om de GPU dynamisch in/uit te schakelen? Dus bij pagina's zonder dikke grafische content gebruik je gewoon de CPU en anders pak je de GPU mee want ja hier heb je ook niks aan wanneer de rest juist weer trager wordt.

FF draait hier als een trein in win7-64. Heb win7 ook nog nooit gecrashed gekregen.

Dat je denkt dat XP64 stabieler is, lijkt dan ook nogal vreemd. Juist XP64 had grote problemen met stabiliteit omdat de meeste drivers er nog onvolwassen en beta voor waren en het OS steeds naar blue screens trokken. Sinds Vista64 zijn de drivers voor 64bit eindelijk volwassen en daar krijgt win7 ook zijn stabiliteit van.

Bij mij werkt het anders altijd prima, ik heb in al die jaren dat ik FF gebruik misschien 5 keer een crash meegemaakt. In dezelfde tijd heb ik veel vaker een IE crash meegemaakt, terwijl ik die veel minder gebruik. Waarom vind je dat FF instabiel genoemd kan worden?

Ik durf te wedden dat zoiets per pc kan verschillen. En zelfs wat je bezoekt maakt verschil uit. De ene site bevat nette javascript, en een andere site allemaal slecht opgemaakte experimental javascript. Dan klapt IE inderdaad nog weleens op. Zo kun je wel doorgaan. Maar de hoofdoorzaak van crashes binnen browsers ligt dus niet enkel aan de browser.

[Reactie gewijzigd door Grrmbl op woensdag 25 november 2009 15:32]


Zo vond ik persoonlijk de 2.x branche niet helemaal stabiel lopen en was voor mij vooral 3.5 een grote verademing. Dus het is maar net op welke systemen je zit en welke systemen je test. Bij mij ging dat vooral om de nieuwste besturingssystemen bijvoorbeeld.

firebug integreert zich zelf heel diep in firefox en staat er dan ook bekent om dat hij firefox minder stabiel maakt. Maar het is inderdaad een onmisbare tool voor webontwikkelaars. Ik werk er zelf ook op dagelijkse basis mee.

Overigens is Aero Peek zelf ook niet foutvrij, ik heb op diverse andere applicaties dat'ie gewoon niet goed werkt. Dan moet je eerst het venster openen en daarna werk Aero Peek pas weer...
Dat ligt vaak ook aan de applicatie, sommige applicaties lijken niet goed om te gaan met redrawen als de applicatie geminimaliseerd is. Bijvoorbeeld Excel, die op een bizarre manier omgaat met meerdere documenten (1 venster, maar meerdere icons op de taakbalk).

Ik vind het geweldig hoe open software steeds beter wordt.

Heb onlangs voor het eerst Ubuntu geinstalleerd op een ouder systeem en het draaide meteen als een tierelier inclusief Firefox.

Hulde aan de mensen die hun tijd investeren om dit soort systemen verder te ontwikkelen. Ga vooral zo door.

Ik geloof daarom niet dat je skepsis helemaal op zijn plaats is voor free ware.

[Reactie gewijzigd door G-bird op woensdag 25 november 2009 11:04]


Freeware en "Open-Source" zijn niet hetzelfde.

Wat is Aero Peek?, en waarom is het belangrijk voor het gebruik van een browser?

Ken je Google? Waarom ga je daar niet even 'windows aero peek' intypen?

Natuurlijk kent-ie Google. En ja, elmuerte had misschien wel eerst kunnen zoeken om te vinden wat Aero Peek is.

Rest de vraag...
waarom is het belangrijk voor het gebruik van een browser
. En die vraag wordt echt niet door http://windows.microsoft....s7/products/features/peek beantwoord.

Het lullige is dan ook dat iedereen wel leuk 'Aero Peek' roept, maar dat ze het eigenlijk over de taakbalk 'peek' hebben. De Windows 7 taakbalk laat al je document vensters van hetzelfde programma onder 1 knop (die van het programma) zitten. Met je muis over die knop, en dan kan je zien welke document vensters er open zijn; die worden in miniatuur weergegeven.

En daarin zit dan ook de browser koppeling.. Met IE8 zie je dan elk tabblad wat je open hebt als een apart icoontje. Bij browsers die deze feature niet ondersteunen zal je alleen een miniatuur zien van het huidige tabblad.

En dat is dus echt extreem vervelend, dat je al je tabs als iconen ziet. Want de hele reden dat tabs bestaan is om ze NIET op de taakbalk te hebben. Anders had je wel een nieuw scherm geopend toch? |:(

Het is wel vervelend. Net zo goed dat ik met Alt-Tab gewoon alle losse tabbladen van de browser wil kunnen aanspreken (kan ook niet in MSIE en ik mis het).
Nu moet ik als ik van programma X naar een willekeurige tab in de browser wil met alt-tab eerst naar de browser en dan naar de tab. Dat zijn 2 handelingen, terwijl het ook in 1 zou kunnen.

De taakbalk peek is daar nu een kleine oplossing voor. Even hooveren over het icoon van de browser en dan direct de juiste tab kiezen. (ze staan dus niet in je taakbalk !!)

Als Aero Peek dat irritante tab-preview scherm is van Internet Explorer in Windows 7 als je naar Internet Explorer wil switchen, hoef ik het ook niet; als ik erop klik wil ik de browser direct in m'n beeld hebben, niet een of andere tab-selectie dialoog.

Het is een venster selectie dialoog, geen tab selectie dialoog. En dat is even wennen, maar wel heel handig.

Bovendien zou de Direct 2D-browser nog crashgevoelig zijn en kunnen er rendering-artefacten optreden.
Raar als het een expirimentele build betreft :? Maar wel een goede richting waar men in gaat. Met de steeds sneller wordende internetverbindingen wordt een browser toch steeds meer de bottleneck als het gaat om rendering van complexe websites.

Met de steeds sneller wordende processoren betwijfel ik dat. Je hebt zeker een punt hoor, maar hoe vaak moet jij nog echt wachten op een pagina die aan het renderen is? Volgens mij valt dat tegenwoordig ook wel mee. Niettemin is dit natuurlijk wel een mooie ontwikkeling.

Heb je niks meegekregen van de nieuwste trend? Steeds meer kleine apparaten (nettops, smartphones) willen een volwaardige browser hebben. Die apparaten hebben een beperkte CPU-capaciteit. Dingen renderen gaat veel efficiënter met een GPU, dus kan het aardig wat accutijd schelen om dat soort dingen uit te besteden aan de GPU :)

Eh ja, leuk bedacht maar juist nettops en smartphones hebben een abominabele GPU aan boord waarbij dit dus helemaal niet gaat helpen, mogelijk zelfs het tegendeel, smartphones met DX10 GPU's zijn al helemaal dun gezaaid.

Dit is een eerste versie die een DX10-GPU nodig heeft. Je ziet de trend dat GPU's op smartphones steeds beter worden, dit is een eerste stap (of eigenlijk een 2e omdat in Linux 2d-versnelling al mogelijk is).

Vanaf Opera Mobile 9.7 op Windows Mobile word het beeld al via OpenGL-ES geaccelereerd door de 3D chip, indien mogelijk. ;)

Is eenzelfde techniek ook op Unix-platformen beschikbaar?

OpenGL?

Daarnaast zou er ook nog gedacht kunnen worden aan het steeds meer opkomende CL. Hiermee zouden ook andere taken, zoals Javascript en Flash, uitbesteed kunnen worden aan de (GP)GPU.

Het enige nadeel is wel dat de mensen dan ook OpenCL moeten ondersteunen, wat momenteel nog niet geheel het geval is.

Volgens mij is OpenCL bedoelt voor het uitvoeren van standaard code (berekeningen enzo), wat dus het tegenovergestelde is van wat hier bereikt moet worden, namelijk *graphics* door de gpu laten renderen (oftewel waar de gpu voor bedoelt is).

Het is denk ik niet zinnig om alles maar aan de GPU uit te besteden. We hebben tegenwoordig quadcore bakken die met z'n vieren snel zat zijn voor wat de browser nodig denkt te hebben. Je wil toch niet dat zometeen de CPU idle is en de GPU maximaal belast wordt, zodat dáár de vertragingen vandaan komen.

Javascript zou eens truly multithreaded mogen worden (anders kan het niet eens naar de GPU trouwens), zodat het goed over de CPU-cores verdeeld kan worden. Maar voordat dat gebeurt, zal het eerst ontzettend goed geoptimaliseerd moeten worden, desnoods door te compileren naar machinetaal (hetgeen in sommige browsers al voor een deel gebeurt).

Als er een render-backend is voor Cairo die naar bijvoorbeeld OpenGL rendert, dan kun je iets vergelijkbaars onder de diverse Unix-varianten bereiken...

Volgens mij is dat ook al aanwezig in de huidige Firefox...

OpenGL en framebuffer. Die zijn alleen wel wat ruwer dan Direct 2D. Direct 2D is een kant en klare API. Een vergelijkbaar iets zou SDL kunnen zijn. Die is ook nog 'ns cross platform, maar SDL is voor andere doelstellingen ontwikkelt, dus ik vraag me af of dat allemaal goed zou kunnen werken. :)

Voor zover ik weet is SDL meer vergelijkbaar met DirectX, een soort overkoepelende API waar je alles mee aan kunt spreken: graphics, sound, input, etc.
Waar je vandaan haalt dat OpenGL wat "ruwer" is dan Direct2D zou ik niet weten. D2D was nieuw in Vista, OGL bestaat al heel veel langer, en is ook een kant en klare API.
Het valt me op dat windows gebruikers vaak DirectX nogal overschatten, terwijl je met D3D ofzo echt niet meer kunt dan met OGL. Sterker nog, OGL is over het algemeen sneller. Probeer het maar eens uit in games van vroegah die zowel een OGL als een D3D renderer hadden. De OGL renderer was eigenlijk altijd sneller en verschil in beeldkwaliteit zag ik niet. Wat ik wel zag was enorme mouselag in D3D mode (dat het beeld niet direct op de muis reageert) die niet in OGL aanwezig was. Helaas is de games industrie nogal gebrainwashed door MS en maken ze bijna alleen nog D3D games |:(

Wat jij verteld komt me bekend voor, (Unreal Tournament) maar vergeet niet dat het over vroeger gaat.

Tegenwoordig is OpenGL echt niet sneller meer, het is juist OpenGL die achter loopt qua futures enz

Het leuke is dat Firefox vanaf versie 3 Cairo gebruikt. Deze library heeft verschillende backends (GDI, Quartz, etc.) Nu heeft Bas Schouten dus een Direct2D backend geschreven, maar er was ook al een OpenGL backend (via Glitz :))

edit: en er is natuurlijk XRender, volgens mij ook hardware accelerated.

[Reactie gewijzigd door JanDM op woensdag 25 november 2009 11:11]


EXA en XAA zijn al bestaande 2D-versnellings APIs onder X11.

Niet alles wat een *nix kernel heeft draait X11.

Maar wel alles dat een *nix-kernel en Firefox draait draait X11.

Een andere oplossing zou het bovengenoemde SDL zijn in combinatie met OpenVG. Voor die laatste moet driversupport echter nog komen.

Nogmaals een bewijs dat 'gezonde' concurrentie goed is voor een product en bijgelovig voor de consument. Al moet die laatste voor deze producten in dit geval niet betalen :*)
Dat de GPU ook werk krijgt buiten gamen/photoshop is ook een goeie ontwikkeling. Die staat, in mijn geval althans, anders alleen wat warmte te produceren.
vooral technieken als svg-graphics en css-transforms kunnen volgens Schouten profiteren.
Vooral de css transforms lijken me mooi meegenomen. Nu nog starten met een globale integratie van CSS 3.0...

offtopic:
De ontwikkeling voor IE9 is al bezig, waarom moet ik en vele anderen nog steeds IE5 en 6 ondersteunen; wij zijn veel te goed. 8)7

CSS 3 ondersteuning is leuk, maar je hebt er weinig aan aangezien jij ook rekening wilt houden met oudere browsers. Want jij hoeft geen IE5.5 of IE6 te ondersteunen, dat is natuurlijk jouw eigen keuze. Bij mij in het bedrijf is het policy om alles vanaf IE7, Chrome 2, Safari 3, Opera 9 en Firefox 3 te ondersteunen. De major versies die één versie nummer daaronder liggen die worden niet officieel ondersteund, maar worden wel getest. Is de pagina dan bruikbaar (met renderfouten) dan komt deze gewoon de kwaliteitscontrole door.

Waarom deze specifieke keuze? Omdat het onzin is om een browser uit 2001 te ondersteunen waarvan 1) het marktaandeel gestaag terugloopt en 2) vaak nogal wat extra code vereist wordt. Mijn klanten hebben er verder geen problemen mee tot nog toe en die zijn vaak ook niet cutting-edge bezig. Die updaten hun Windows vaak gewoon :)

Offtopic: Kijk dan ben je goed bezig. Wij zetten gewoon een IE6 bar er in superhanding! http://ie6update.com/
niks meer iets recht zetten..margins,paddings etc. ... IE 6 moet weg!

Ontopic: Heel goed dat ze bezig zijn om elkaar zo te pushen om nieuwe browsers uit te brengen. Dit kan ook voor ons delevopers in de toekomst veel meer mogelijkheden brengen.

eindelijk :p maar heeft iemand benchmarks dat word aangetoond dat hij sneller is?

Hier op geforce 7xxx is ie langzamer... was te verwachten maar toch.

Het staat ook in het artikel dat DirectX 9 kaarten langzamer zijn of in ieder geval maar een kleine performance boost krijgen ten opzichte van DirectX 10 kaarten.

als ze dit nou echt goed uitwerken ben ik al helemaal een trouwe gelukkige firefox gebruiker :)

maargoed,
gaat dit niet ten koste van je game fps? want ik heb vaak genoeg een game aanstaan en een website met eventuele informatie en etc. ( nee, geen cheats. :P )

Vast wel, maar games hebben ook veel CPU kracht nodig en dat heb je dan weer vrij. Ik denk dus dat het weinig impact zal hebben.

als ze slim zijn, introduceren ze een flag. Zodra die aanwezig is op een website, kan (en wordt) de pagina via de GPU gerendered. Zo niet, dan gaat het nog gewoon op de standaard (ouderwetse) manier. Op die manier houd je compatabiliteit, en kunnen webmasters testen (en debuggen) of de gpu rendering in orde is.


Zodra de engine dan stabiel is, kan overgegaan worden op standaard rendering via de gpu. Ik heb namelijk liever niet dat er een renderartefact optreed tijdens het internet bankieren...

Alleen als webdeveloper wil je zo weinig mogelijk door anderen verzonnen flags in je site. Bij Microsoft hebben ze voor IE8 ook een tag verzonnen om in compatibility mode te draaien. Gelukkig gebruikt men die weinig, maar anders is het iets wat tot in de lengte der dagen je blijft achtervolgen. In principe zet je voor elk HTML document een doctype en zal elke browser de juiste rendering toepassen. Daarbij weet een browser met de juiste doctype wat ie kan verwachten, het zijn namelijk standaarden.

Wanneer de engine niet stabiel is is dat een probleem aan de softwarekant. Daarom is het stuk software nog in alpha-status.

Rendering door de GPU zou geen invloed moeten hebben op de weergave (alleen de prestaties) dus is een flag is niet alleen om andere redenen onwenselijk maar ook overbodig.

Gebruikers die met een in alpha staat verkerende browser het wereldwijde web verkennen kiezen daar zelf voor en moeten dus ook niet vreemd opkijken als hun alpha software wel eens fouten maakt. Er is geen reden om de ontwikkelaar van een site hiermee te gaan vermoeien.

Wordt dit echt merkbaar? Bijna elke site staat bagger vol flash adds, animated gifs, noem het maar op, de vertraging komt veelal (in mijn geval) daarvandaan.

Hmm, net even gedownload (en post dit ook via die nieuwe beta) maar ik zie geen verschil. http://people.mozilla.com/~vladimir/demos/photos.svg is nog steeds schokkerig en gebruikt 50% CPU op een dual core systeem. Heb hier wel een DX10 kaart. Ik zie vast iets over het hoofd.

Heb je de DX10 software/drivers ook geïnstalleerd? Als je XP draait dan lijkt het mij van niet. Aangezien het hebben van een DX10 kaart geen garantie is dat ie ook de DX10 features gebruikt, is dat iets wat je moet nagaan.
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 10:54 Playlogic ziet verlies toenemen
Vorige 10:04 Nokia brengt smartphone met capacitief touchscreen uit
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011