Google wil Chrome voor Android sneller maken via gpu-rendering

Google werkt met Project Ganesh aan het versnellen van de Chrome-browser voor Android door meer taken af te laten handelen door de gpu. De ontwikkeling is nog in een vroeg stadium en werkt vooralsnog alleen in builds van Chrome die bij Google intern worden gebruikt.

De komst van Project Ganesh werd aangekondigd tijdens een door Google georganiseerde ontwikkelaarsbijeenkomst, zo meldt Android Police. Het project draait met name om het renderen van webpagina's binnen Chrome voor Android af te laten handelen door de gpu. Vooralsnog worden de berekeningen uitgevoerd door de cpu, wat de browser in sommige gevallen langzaam doet aanvoelen, bijvoorbeeld bij scrollen.

Google heeft Project Ganesh al werkend gekregen binnen Chrome voor Android, maar heeft nog geen werkende versie uitgebracht. Vooralsnog draait Project Ganesh alleen binnen een interne Canary-build, waarbij nog onduidelijk is wanneer gebruikers er over kunnen beschikken. Met het sneller maken hoopt Google de browserinterface op 60fps te kunnen laten draaien.

Overigens werkt vooralsnog slechts 15 procent van de webcontent met de technologie van Project Ganesh. Daardoor kunnen lang niet alle webpagina's sneller worden gerenderd. Dat moet in de toekomst waarschijnlijk worden verbeterd.

Reacties (75)

[Verwijderd]

Ik begrijp dat nu Chrome al alle cores gebruikt van m'n nexus 5... toch snap ik niet hoe die browser ondanks het overschot van cpu power nog altijd langzamer werkte dan de Blackberry browser op m'n Q10 die werkt met een snapdragon s4plus ipv snapdragon 800.

Ook met de HTML5test scoort de 10.3 browser iets beter dan Chrome 36.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:45]

[calvinturbo]

Ik moet je helaas hierin gelijk geven. Chrome (Beta) for Android is nog steeds niet zo smooth als je zou verwachten. Ook Safari op iOS gaat stukken smoother dan Chrome op Android.

Ben benieuwd of Chrome op Android straks ook zo butter smooth is als de rest van het OS

[Reactie gewijzigd door calvinturbo op 23 juli 2024 08:45]

[Dylan93]

Ik moet je helaas hierin gelijk geven. Chrome (Beta) for Android is nog steeds niet zo smooth als je zou verwachten. Ook Safari op iOS gaat stukken smoother dan Chrome op Android.

Ben benieuwd of Chrome op Android straks ook zo butter smooth is als de rest van het OS

Dat komt omdat Apple wel zo'n beetje alles GPU accelerated doet, grotendeels al vanaf iOS 1, heb ook nooit gesnapt waarom Google dit niet doet.

[Thekilldevilhil]

Tot android 2.2(?) had je zelfs geen GPU nodig. Ik denk dat het komt omdat ze zo ontzettend veel hardware moeten ondersteunen en armv7 de enige ISA die echt breed gebruikt is in andorid telefoons is terwijl je een heleboel verschillende GPU's hebt. Het is gokken natuurlijk maar ik hoop wel dat ze er snel wat aan doen.

[Verwijderd]

Ja apple heeft altijd hun eigen socs gebouwd inderdaad. Stuk makkelijker om mee te programmeren lijkt me.

Nog steeds best een kunst van google om het met verschilllende gpus te laten werken denk ik zo.

[Vburen]

*gekozen, niet gebouwd. De eerste socs waren vrijwel off the shelve.

Verder heb je helemaal gelijk. De enige breed ondersteunde API is opengl mobile en daar heb je ook weer veel te veel versies en ondersteuningsniveaus van.

[Verwijderd]

Komt ook omdat iOS de Interface anders opbouwt. Eerst worden alle elementen geladen en geplaatst. Pas daarna wordt de touchinterface geactiveerd. Op Android gebeurt dit tegelijk. Manier van renderen is dus anders.

Voordeel: Bij Android kun je sneller door de interface heen gaan.
Nadeel: Dat gebeurt dan soms hokkerig

Bij iOS omdraaien

Source:
http://m.imore.com/android-ui-smooth-ios

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:45]

[_Thanatos_]

Het gewoon maar op de GPU renderen is geen garantie voor gelikte animaties op 60fps. Daar komt wel meer bij kijken dan de boel maar even forwarden naar deGPU en zeggen "doe jij dit ff?"

Daarbij moet je ook aan het verbruik van een apparaat denken. Een GPU is misschien sneller, maar vebruikt ook stroom. En performance moet altijd uit de lengte of uit de breedte komen. Een langzamere GPU zou voor dezelfde actie weleens meer stroom kunnen trekken dan een CPU, omwille van of het sneller/smoother is wat er gedaan moet worden.

[OMX2000]

De jongens bij Apple zijn niet helemaal gek hè. Er wordt enorm veel bijgehouden qua energiegebruik in iOS. Check deze jailbreak app die verborgen iOS functionaluteit mbt energieverbruik zichtbaar maakt. http://www.idownloadblog....tery-usage-menu-in-ios-8/

[SV_25]

Je hebt gelijk. Dit is ook iets waar Sony zijn gebruikers voor waarschuwde toen de ICS update eraan kwam. Gpu rendering zou in de meeste gevallen juist slechter zijn voor de batterij. Verklaring hier: http://developer.sonymobi...ween-gingerbread-and-ics/
vb: "Another effect of the hardware acceleration is that it can make the battery drain faster in some cases. An example of this is video playback, where the hardware acceleration requires every video frame to be run through the GPU, thus making the system use more power than it would have without HW acceleration."

[Verwijderd]

Komt dat niet doordat Chrome op veel verschillende socs moet draaien en Safari op enkele?
Dat is een stuk beter aan te sturen...

Prima dat Google hier mee bezig is, ik hoop dat ze echt vorderingen kunnen maken...
Prima browser wat mij betreft.

[HerrPino]

Dat komt niet alleen daardoor. Het komt ook doordat de Android's kernel anders werkt als de kernel van iOS. Android zal nooit zo smooth aanvoelen als iOS, of Windows Phone ... op dezelfde hardware. Dat heeft Google zelf ook al ooit aangegeven. Dat heeft voor een deel te maken hoe Android's Linux kernel onderwater met UI threads omgaat. Waar in iOS en Windows Phone blijkbaar voorrang gegeven kan worden aan UI afhandeling, gebeurd dit schijnbaar niet in de Linux kernel. Android is ontworpen om alles te ondersteunen, iOS en Windows Phone om een goede user experience te geven. Een manier om dit probleem te minimaliseren is door er krachtigere hardware tegenaan te gooien.

[Reactie gewijzigd door HerrPino op 23 juli 2024 08:45]

[PPie]

Waar in iOS en Windows Phone blijkbaar voorrang gegeven kan worden aan UI afhandeling, gebeurd dit schijnbaar niet in de Linux kernel.

Apart? Het verhogen van thread prioriteit kan toch ook in Linux?
(Linkje)

[NotSoSteady]

Zal wel meevallen:

Overigens werkt vooralsnog slechts 15 procent van de webcontent met de technologie van Project Ganesh. Daardoor kunnen lang niet alle webpagina's sneller worden gerenderd. Dat moet in de toekomst waarschijnlijk worden verbeterd.

[tijm15]

Op mijn xperia z3 compact draait Chrome super smooth.

[chimnino]

K vind m ook lekker draaien op mn Z3C. Zie t probleem niet zo. Maar soit, als ze het smoother kunnen maken via GPU zonder een grote impact op het verbruik van je accu, do it!

[Thekilldevilhil]

Op de Z3c van mijn vrinedin draait hij goed maar supersmooth zou ik heb niet willen noemen...

[Kuusj]

Netzogoed snappen veel andere mensen niet dat je 800 euro voor een basismodel iPhone 6 neerlegt...

In ieder geval, zo traag vind ik Chrome (beta) niet aanvoelen op mijn Nexus 5. Je merkt wel dat het niet op 60FPs draait maar echt hinderlijk kan ik het niet noemen. Als dit natuurlijk wel zou kunnen is het meegenomen.

Zou dit misschien ook de accuduur positief kunnen beïnvloeden? Als nu al de 4 cores op de 2,23Ghz draaien zal dit waarschijnlijk wel wat meer verbruiken dan een Adreno 320 op 450Mhz.

[Socket 1337]

In de praktijk is mijn lg g2 regelmatig sneller dan mijn iPad mini retina. Ook is de g2 consistenter, dwz. dat pagina A laden meestal 5 seconden kost, en niet de ene keer 4 seconden en de volgende 15 etc. Daar heeft de iPad soms last van. Maar dat heeft volgens mij veel meer met de WiFi / netwerk afhandeling te maken dan de cpu.

[oef!]

*kuch* safari op mijn ipad3 wordt volledig in elkaar geschopt door Chrome op mijn Nexus 7. *kuch*

[Verwijderd]

Ik dacht dat Apple lang mee ging? Bejaard?

[seapip]

Chrome is dan ook de enige browser die daadwerkelijk alles ondersteund zoals het hoort op de desktop, tis letterlijk een desktop port zowat. Het voordeel hiervan is dat deze evengoed werkt met het renderen van sites als de desktop verianten (web devs stellen dit op prijs). Bijvoorbeeld safari ondersteund nog steed geen position: fixed; op iOS wat het toppunt van belachelijk is...

Dus zoals het artikel al zegt is het nu een kwestie van het meer optimaliseren voor de telefoon van de chrome engine.

[bskibinski]

Position fixed werkt wel op iOS.
Al dan wel een beetje buggy.

Maar je hebt gelijk, chrome is zeer fijn om mee te werken, alhoewel alle browsers tegenwoordig wel op een lijn liggen.

[n8n]

Position fixed werkt zeker al vanaf iOS 6, mogelijk al vanaf 5. Wat je zegt is dus klinkklare onzin. Apple heeft position: sticky ook nog toegevoegd wat nu als draft in webkit zit en het geliefde 'fixed binnen een element' native implementeert, bijvoorbeeld wat thesaurus.com heeft wat met javascript gedaan wordt en daar onwijs choppy werkt.

[Reactie gewijzigd door n8n op 23 juli 2024 08:45]

[curry684]

Position:fixed werkt best aardig, het is voor ons webdevs storender dat onScroll nog steeds crippled is (single shot na beeindiging scrollactie). Dat is een van de vele performanceoptimalisaties waardoor iOS Safari wel erg rap voelt, maar ook onder iOS 8 nog doorlopend barst van de renderfouten - ik typ dit op een iPad Air 2, super smooth, maar de fixed header hier van Tnet verdwijnt doorlopend half tijdens het scrollen.

Als hierboven al ergens gezegd is het een verhaal van lengte of breedte. Een desktopbrowser integraal porten kost kruim en overhead, oftewel accu en sloomheid, waarvan akte in Chrome (overigens amper merkbaar op een recente Android uit de Apple prijsklasse). Optimaliseren voor mobiel levert renderfouten en problemen, waarvan akte in iOS Safari.

Geef het een jaar of 2 en ze zijn weer identiek.

[n8n]

Ook onscroll werkt met iOS 8. Scroll events zijn de meest resource intensieve events in javascript, performance wise helemaal geen rare zet. Dat je fixed header wegloopt is wanneer je zoomniveau niet op 100% staat.

[Whatson]

De 'fixed' header hoort zo te werken. Als je naar beneden scrolled verdwijnt hij, maar bij het naar boven scrollen komt hij weer tevoorschijn. Dit geeft je meer ruimte op het scherm voor de content.

[McBrown]

Net andersom

Sorry my bad, je hebt gelijk

[Reactie gewijzigd door McBrown op 23 juli 2024 08:45]

[seapip]

zoals @bskibinski al hierboven zegt werkt het wel maar is het amper bruikbaar wegens de vele bugs(in iOS 8 blijken de meeste bugs opgelost te zijn).

[n8n]

Alle issues van die site zijn met iOS 8 van de baan, de meeste met iOS 7 al. Je statement baseren op position fixed is gewoon een rare maar dat zal gezien de moderatie wel aan mij liggen.

[batjes]

Hmm. IE op wp8.1 is dezelfde trident engine als IE op windows 8.1.
Dus hoezo chrome is de enige?

Is overigens ook al gpu accelerated.

[GAIAjohan]

En stukken sneller dan Chrome op Android. Toen ik van Windows Phone weer terug ging naar Android was dit een van de grootste hekelpunten.
Een tweede is dat een Android-systeem na X tijd altijd traag lijkt te worden en een reset nodig heeft. Menu laden duurt soms bv wel een seconde. Terwijl games gewoon soepel lopen...

[Reactie gewijzigd door GAIAjohan op 23 juli 2024 08:45]

[batjes]

IE10 was met wp8 nog redelijk brak. Maar wp8.1 IE11 valt echt niets over te klagen behalve zijn lage error tolerance (javascript op hol en meteen process killen ipv minuut oid wachten) naar mijn mening wat flexibeler mag.

Wp word ook langzamer na langer gebruik, maar heeft naar mijn ervaring voornamelijk te maken met de hoeveelheid meuk je op je telefoon hebt staan. Maar veel verschil is dat niet en spreek je over tienduizenden files

[Verwijderd]

Heb je al gezien hoeveel al de effecten vreten? Scroll tot je niet meer kan in welke richting dan ook, effect. Nogal irriterend en niet nuttig. Net nog gezocht hoe je dat uit zet in lollipop, maar nog niet gevonden.
Een browser die al je power nodig heeft, van den zotte...

[seapip]

Je bedoel list scroll effect? die kan je niet uitzetten maar die gebruikt ook amper resources...

Je kan wel de tabblad previews uitzetten in chrome waardoor je alleen een lijst krijgt maar dit scheelt ook amper resources, de interface van chrome is namelijk niet echt het probleem, het renderen van de webpaginas kost gewoon nog te veel resources.

[desalniettemin]

Ik heb Chrome vervangen door Firefox met AdblockPlus. Of die sneller is dan Chrome weet ik niet, maar voor mij is het snel genoeg.

[watercoolertje]

En wat is nu je punt en wat heeft dat met het artikel of zijn bericht te maken?

[Mavamaarten]

Ik zie het probleem dat veel mensen met chrome hebben niet. Misschien ligt het aan het feit dat ik Lollipop draai, maar hier draait chrome in elk geval super smooth. Ik zou het zelfs sneller dan de stock browser durven noemen. Hier is even een snelle demo. Hoezo is dit traag? (ik zit zelfs op 3G)

Dit is overigens op een Xiaomi Mi2, een toestel van 2 jaar oud.

[Reactie gewijzigd door Mavamaarten op 23 juli 2024 08:45]

[Verwijderd]

Op mijn Nexus 4 met Android 4.4 is hij net zo soepel als in jou filmpje. Ik zie geen probleem.. waarom is dit zo verschillend bij toestellen?

[Jorick]

Neem in het verschil dan ook even mee dat de Nexus 5 een scherm met een resolutie van 1920x1080 pixels heeft terwijl de Q10 maar een resolutie van 720x720 pixels heeft wat aanzienlijker makkelijker te renderen is. Daarnaast zegt de HTML5test score helemaal niets over de prestaties van de browser maar alleen over de mate van ondersteuning van HTML5 (en dat verschil is maar 1 punt, 491 om 490 dus echt verwaarloosbaar). Bovendien bevat Google Chrome features die de BB browser moet missen zoals text reflow, tabs & bookmarks synchronisatie en translate om er een paar te noemen en die zorgen ook voor langere laad- en rendertijden. Probeer Google Chrome eens op de Q10, ik betwijfel ten zeerste of ie daar sneller werkt dan op de Nexus 5...

[Reactie gewijzigd door Jorick op 23 juli 2024 08:45]

[HakanX]

De passport heeft 1440 x 1440 pixels en daar werkt het ook veel sneller op. Android heeft gewoon heel veel overhead das geen geheim. Zowel BB OS10 als iOS als WP draaien op dezelfde en langzamere hardware rondjes om een Android toestel.

[sfranken]

Dat is makkelijk gezegd. BlackBerry, Apple en MS hoeven een zeer beperkt aantal SOC's te ondersteunen. Google moet ervoor zorgen dat Android op honderden hw configuraties draait. Dat is wel even een verschil he?

[Verwijderd]

Het verschil van 502/503 punten voor de 10.3.1 browser html5score tegenover chrome is inderdaad verwaarloosbaar en Chrome heeft meer functies en services, en werkt inderdaad beter op een telefoon met zware soc dan met een lichte soc.

Feit is dat als ik een blackberry pak of het nou de Q10 of Passport met hogere resolutie is, hij sneller en dus fijner browst dan de nexus. Wat dat betreft is de hardware acceleratie zeeer welkom op Chrome, omdat het waarschijnlijk een snellere en fijnere browse ervaring gaat opleveren op androids.

[Verwijderd]

Ik kan je hier in gelijk geven. Op mijn note 4 is Chrome ook niet smooth (met snap 805 dan nog). Standaardbrowser van Samsung is echter top qua prestatie en 'smoothness'. Gebruikt wel enorm veel ram maargoed (330 MB)

[bartwindt]

Blackberry q10 met een schermpje van 3.1" resolutie 720 bij 720. Tegenover een nexus 5 met 4.95" met resolutie 1920 bij 1080 geeft toch ook een verkeerd beeld denk ik. Het moet allemaal gerenderd worden of niet. mischien dat ik het verkeerd zie.

[WoutervOorschot]

Dat zou tijd worden, chrome is nou niet echt heel soepel op android.

[_Thanatos_]

Op de desktop is het anders ook een monster. Firefox is bij mij veeeel sneller.

En ja, ik test dat op een hele dikke workstation.

[Swerfer]

Ligt dat aan Chrome of aan Android?

Laat ze eerst Android sneller maken. Lollypop komt al aardig in de richting...

[Verwijderd]

Ik weet niet wat jij doet met je telefoon, maar een Nexus 5 ( een toestel van rond de 200 euro tweedehands en anderhalf jaar oud) is gewoon retesnel. Sneller dan een iPhone 6 bijvoorbeeld. Ik moet de eerste telefoon nog tegenkomen die sneller is dan de Nexus 5. Conclusie: Android is snel, de skins van fabrikanten zijn langzaam.

OT: Ik heb eigenlijk helemaal geen problemen met Chrome. Ik gebruik de standaard browser van Xiaomi, wat onderhuids dacht ik gewoon een versie van Chrome is. Het moet toch ook lukken om met alle power die we tot onze beschikking hebben een browser normaal en snel te laten kunnen lopen?

[Thekilldevilhil]

Helemaal eens, je N5 is in mijn ervaring ook mooi snel en soepel. Maar dat gevoel heb ik wel op al mijn high-end telefoons/tablets dus dat zit wel goed.

[z1rconium]

Google zegt hier zelf: Chrome is traag en we gaan dit proberen te fixen door dit project te starten. Jij zegt er is niets aan de hand....

hoe rijmt dit met elkaar ?

[Ventrigo]

Google zegt:"Het project draait met name om het renderen van webpagina's binnen Chrome voor Android af te laten handelen door de gpu. Vooralsnog worden de berekeningen uitgevoerd door de cpu, wat de browser in sommige gevallen langzaam doet aanvoelen, bijvoorbeeld bij scrollen."

Dit zegt dus eigenlijk dat ze weten dat de GPU websites beter kan verwerken dan de CPU. Chrome is niet traag, maar werkt sneller op een GPU dan op een CPU. En als je scrolled is het meer iets grafisch dan dat er iets met de achterliggende code gebeurt (tenzij je een actieve code hebt die wordt aangeroepen tijdens het scrollen )

[Tunestwo]

Het ligt aan chrome dat is hierboven ook al geconcludeerd.. Android is op zich zelf wel soepel maar chrome blijft somehow heel zwaar.

[Verwijderd]

Ik draai chrome anders gewoon smooth op mijn LGG3. Geen probleem... .. .(draai wel CM12...)

[Verwijderd]

Volgens mij is dat heel slecht voor je accuduur ...

[Verwijderd]

Hoezo? Je laat dan een GPU doen waar hij goed in is, in plaats van dat je een CPU iets laat doen waar hij heel slecht in is en erg traag in is. Dan hoef je dus korter te renderen en waarschijnlijk ook niet een stroomslurpende quadcore op 100% te laten draaien. Nee, dan hoef je maar kort te renderen op iets wat relatief zuinig is. Ik denk dat het beter is voor je accu dan alleen maar software acceleration.

[_Thanatos_]

Een transition die 1 seconde duurt, duurt 1 seconde. De GPU gaat daar niet opeens korter over doen

[calvinturbo]

Maar het kan wel zijn dat de GPU minder % kracht gebruikt tijdens die transition dan de CPU, waardoor er minder stroomgebruik is

[Verwijderd]

Dit gaat over Chrome. Daarin mag een webpagina zo snel mogelijk zijn, en het renderen over de GPU gaat sneller en is dus wel belangrijk. Het is niet alsof een site een minimale tijd heeft die het laden moet duren. Plus dat, zoals hieronder aangegeven, de GPU minder zijn best hoeft te doen dan de CPU en dus stroom bespaart.

[_Thanatos_]

Dat kun je dus helemaal niet zeker weten. Er zijn vast genoeg pc's die een heule snelle CPU hebben, maar een laffe videochip.

[YopY]

Nee, maar wel efficienter, omdat een GPU geoptimaliseerd is voor beeldverwerking.

[Rudie_V]

Ik lees hier bij meerdere dat chrome traag is, maar ik heb er eigenlijk geen problemen mee. Op welke sites is dat dan bijvoorbeeld? En is het de mobiele site of de desktop site?
De sites die ik bekijk reageren eigenlijk gewoon normaal en snel in chrome.
En ik heb nog een sony xperia t met eerst firmware, dat is maar een dual-core.

[Verwijderd]

Hangt er misschien vanaf wat je gewoon bent? (op je telefoon )

[Rudie_V]

Dat sites gewoon vloeiend te scrollen zijn als ze geladen zijn. Ook met vergroten heb ik geen problemen. Dus gewoon smooth

[Mithrildor]

Ik hoop dat dit de accuduur ten goede gaat komen, want de afgelopen paar maanden is het stroomverbruik van Chrome op Android steeds slechter geworden.

[Verwijderd]

Het verbaast me sowieso dat er niet al veel door de GPU gedaan wordt, reflowing en scaling zijn typisch zaken die een GPU erg goed kan.

[crypt0rr]

Hier geen problemen met Chrome op Nexus 5 op Android 5.0 alles draait soepel.

OT: Hoe zit dat met de accu duur als je de GPU werk laat doen? Kost die niet juist meer energie?

[Anonymoussaurus]

Bij mij loopt het in het algemeen best smooth. Het wordt alleen best laggy als je veel animaties op een pagina hebt en als de website niet is geoptimaliseerd voor smartphones en/of tablets.

[Cinner]

Ik herken ook de problemen niet, voor mijn gevoel zit Chrome op mijn Nexus 5 al rond de 60 fps. Heeft iemand een voorbeeld van een site die het niet goed zou doen?

[Verwijderd]

Ik herken ook de problemen niet, voor mijn gevoel zit Chrome op mijn Nexus 5 al rond de 60 fps. Heeft iemand een voorbeeld van een site die het niet goed zou doen?

Ik ook niet.
Dit soort berichtgeving wordt verkeerd begrepen door mensen die niet bekend zijn met open source.

Binnen open source wordt alle informatie gedeeld goede en slechte en tevens roadmaps ook van experimentele zaken.
Binnen een commercieel software project zou deze informatie niet gedeeld worden, en pas naar buiten komen als de versie publiekelijk gebruikt kan worden.

Mijn ervaring is de zelfde als de jouwe, Chrome doet IMO alles zonder haperen. Dat Chrome en het OS (meetbaar) sneller en mogelijk zuiniger worden als de GPU gebruikt wordt lijkt me logisch.

Daarom IMO een goed en mooi project maar het wil niet zeggen dat de huidige Chrome versie op Android niet vloeiend werkt.

[ikt]

Ik begrijp ook niet waarom Chrome langzamer is dan AOSP browser, vooral nu KitKat een ding is en ze Chromium WebView gebruiken als WebView component. Alles draait op dezelfde engine en ik vraag me dus af wat er eigenlijk aan de hand is met Chrome. Naja, hopelijk wordt het inderdaad beter.