Google brengt 64bit-versie Chrome uit voor OS X

Google heeft kort na de release van een 64bit-versie van Chrome voor Windows ook een 64bit-release van zijn populaire browser voor OS X uitgebracht. Chrome 38, momenteel in het bètakanaal, biedt met de 64bit-versie verbeterde beveiliging, snellere opstarttijden en minder geheugengebruik.

In OS X zijn vrijwel alle applicaties al 64bit, maar Chrome had nog een 32bit-structuur. Met de release van Chrome 38 gaat dat veranderen. De 64bit-versie maakt onder andere gebruik van aslr-technologie, waardoor de browser veiliger moet worden. Daarnaast stelt Google dat Chrome sneller opstart, omdat de browser niet langer allerhande 32bit-libraries hoeft te laden. Tevens zou de browser efficiënter met het beschikbare werkgeheugen omspringen.

De release van een 64bit-versie van Chrome voor OS X volgt na het uitbrengen van een 64bit-versie voor Windows. Bij de Windows-versie beloofde Google dat het afspelen van hd-video's 15 procent efficiënter zou verlopen, maar voor OS X wordt dit niet genoemd. Ook ondersteunt de Chrome 64bit-release voor OS X niet langer 32bit npapi-plug-ins. Volgens Google is dit geen groot probleem, omdat de meeste plug-ins ook in 64bit beschikbaar zijn. Verder meldt Google nog dat Macs met de eerste generatie Intel-cpu's geen gebruik kunnen maken van deze release, omdat deze processors nog volledig leunen op een 32bit-architectuur.

Chrome 38 bevat op alle desktopbesturingssystemen nog een wijziging: de browser toont rechtsboven een aparte inlogfunctie voor een Google-gebruiker. Met de functie kunnen onder andere browserinstellingen en de surfgeschiedenis tussen browsersessies worden meegenomen. Er is ook een gastmodus beschikbaar, waarbij de surfgeschiedenis wordt gewist na het uitloggen met dit account.

Reacties (83)

[blottle]

Hopelijk werkt het veel energie zuiniger dan de vorige versies. Op mijn MacBook Air hield Safari het gerust 12 uur uit, chrome nog geen 5. Dit is de belangrijkste reden waarom ik Chrome niet gebruik.

[Reactie gewijzigd door blottle op 23 juli 2024 05:37]

[Blizz]

Met twee GPU's gebruikt Chrome ook altijd de meest batterijverslindende, zelfs als hw-versnelling uitstaat. Het is een WIndows-port en gemaakt om je Mac-ervaring te verslechteren.

[sfranken]

Kun je een commit laten zien vanuit Chromium waar dit uit blijkt? De code van Chrome is door Chromium gewoon voor iedereen in te zien, en zover ik weet is er voor Linux een branch, voor OS X een branch en voor Windows een branch. De Windows en OS X branch hebben vrij weinig met elkaar gemeen, dan hebben de Linux en OS X branches meer 'in common'.

[Blizz]

Nee, maar het uiterlijk en het feit dat er een apart menu is dat zich niet in de menubalk bevindt wijzen uit dat dit niet ontwikkeld is met het oog op OS X. Het is daarbij vrij tekenend dat de 'OS X branche' telkens een ontwikkeling achterlopen. Dit is geen applicatie ontwikkeld om de Mac-ervaring te leveren of erop aan te sluiten, dat is een feit.

[sfranken]

Klopt, het is een 3rd party applicatie. Bovendien eentje die niet ontworpen is voor één enkel OS.

Als je verder even logisch nadenkt voordat je reageert had je kunnen weten dat Google nooit zo "goed" kan programmeren voor OS X als dat Apple kan, omdat Chrome op veel meer hardware moet draaien dan alleen die paar laptops en desktops van Apple. Je redenatie is dus veel te kort door de bocht, ook je redenatie van een port. De OS X en Linux en Windows versies van Chrome en Chromium zijn geen port maar gewoon native builds op basis van een unified engine en unified layout. Op Linux word er gebruik gemaakt van GTK om de UI de renderen, op OS X geloof ik Cocoa (of de opvolger daarvan). Daaraan kun je al zien dat het geen port is.

[Blizz]

Dat argument gaat mank aangezien Safari en Firefox dit wel kunnen. Het komt erop neer dat Google niet opgewassen is tegen softwareproblemen in hun eigen apps.

Ook een UI port beschouw ik als een port. Prima op Windows, waar elk programma menu's op een andere manier implementeert, niet zoals het hoort op OS X.

[sfranken]

Dus omdat de volkswagen groep met Bugatti een auto kan maken die 400 km/u kan rijden wil dat zeggen dat Fiat dit ook moet kunnen? Je redenatie gaat mank.

Een UI port is geen port. Het is pas een port als de code van het onderliggende programma voor meer dan 90% overeen komt. Wat jij beschouwt als een port en wat de rest van de (software schrijvende) wereld beschrijft als een port is niet hetzelfde dus.

Ooh, ook op Windows is er een standaard manier om menu's te implementeren. Dat weinig devs zich daaraan houden is een tweede

[BoringDay]

Daar zijn algemene standaarden (elk os werk namelijk met een window systeem) voor. Blijft dan toch raar dat MS telkens weer weet te presteren om opties zo te plaatsen dat je eerst moet googlen om erachter te komen.

[Verwijderd]

Er zijn genoeg derden die hun apps wel een echte Mac ervaring weten te geven. Google kiest hier bewust niet voor omdat ze hun eigen design language willen doorvoeren i.p.v. conform te zijn aan het besturingssysteem. Ook heb ik het idee dat ze op bepaalde plekken hun eigen APIs gebruiken i.p.v. die van het systeem te gebruiken. Scrollen bijvoorbeeld gaat in Chrome gewoon niet zo soepel als in de meeste andere programma's.

[sfranken]

Omdat Chrome een eigen render methode gebruikt voor alle UI elementen in de browser (Aura). Dit komt ooit terug als native code maar er zit eerst een laag voor.

[Verwijderd]

Daar heb je het dus al. Ze gebruiken hun eigen meuk i.p.v. gewoon OS X standaarden gebruiken.

[sfranken]

Omdat het op meer platformen dan alleen OS X moet draaien. Ik geef Google gewoon gelijk hierin, het is zwaar naadje om (minimaal*) 3 verschillende codebases te moeten onderhouden álleen voor een UI. Dan kun je gewoonweg niet snel meer innoveren en inspelen op veranderingen in de webdevelopment wereld.

Maar goed, Apple fanboys...

*)
Linux (QT, GTK), Windows (WinForms?), OS X (Cocoa?), Android, ChromeOS (Aura)

[Verwijderd]

En dat heeft dus precies tot gevolg dat zaken zoals scrollen en zoomen naatje zijn t.o.v. apps die gewoon de build-in API's gebruiken. Ik snap prima dat het natuurlijk veel makkelijker is voor Google om hun eigen oplossing te gebruiken en dat over verschillende platformen uit te smeren. Het is alleen wel voor mij een reden om Safari te gebruiken i.p.v. Chrome zo lang het minder presteert dan wat OS X biedt. Heb geen zin om onnodig op die zaken in te leveren op het moment dat ik een goede andere keuze heb.

Verder no hard feelings en het maakt me ook geen Apple fanboy. Als je dat niet kunt accepteren ben je misschien zelf klein beetje een Google fanboy.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 05:37]

[sfranken]

Je reactie kwam aardig over als die van een fanboy door kreten als 'Ze gebruiken hun eigen meuk', wat toch wel spreekt van enige passie. Tenminste, zo kwam het wel een beetje over.

Ik ben trouwens geen Google fanboy. Ik zie de reden waarom ze hun eigen standaard gebruiken, die trouwens onder een abstractielaag native OS X api's aanroept, als valide.

[Verwijderd]

Je bent een beetje overgevoelig heb ik dan het idee. Anyway, zoals ik al zei: ik snap Google's redenen ook alleen werkt het gewoon niet lekker genoeg t.o.v. Safari in mijn optiek. Tot dat verandert is Chrome voor mij geen optie. Al helemaal niet i.c.m. Magic Trackpad.

Wie weet in de toekomst ooit.

[sfranken]

Context en hoe je iets bedoelt is lastig af te lezen ;-) En ach, de "voordelen" van PDD-NOS zullen we maar zeggen?

[frankhan]

Toch altijd blij als er ook wat kennis blijkt uit de antwoorden. Dank @sfranken

Ontopic. Ben heel benieuwd naar deze versie.

[z1rconium]

Daarnaast is Safari volledig geoptimaliseerd om zo weinig mogelijk prik te verspillen.

[huntedjohan]

Waarom zou Google dat doen? Google wint er niets mee als ze jou een slechte Mac ervaring bezorgen met Chrome.

[Blizz]

Er zijn wel wat dingen te bedenken: sommige casual gebruikers zouden met Chrome OS kunnen doen wat ze nu ook al doen. Maar ik weet niet wat de echte reden is, wat ik wel weet is dat de ervaring op deze wijze negatief beïnvloed wordt als Chrome aanstaat.

[S_Chief]

Het is een WIndows-port en gemaakt om je Mac-ervaring te verslechteren.

Eh, onder Windows is Chrome ook een energieverslindend programma. Het scheelt dusdanig veel dat ik terug ben gegaan naar IE (wat overigens erg goed is geworden, alleen de ABP extensie valt tegen qua geheugengebruik).

[Frustus Maximus]

Dat probleem heb ik ook, hoewel ik thuis aan het net gewoon chrome gebruik.

Maar die gebruikers kon je voorheen ook al wisselen bij Google. Je moest bij settings twee gebruikers opgeven, en dan kon je een icoontje kiezen. Als je Google opent staat rechtsboven een icoon waar je op kan klikken om van gebruikers te wisselen. Nu hebben ze er dus alleen een knop van gemaakt. Niet echt nieuw.

[WoutervOorschot]

Net zo op Windows, met internet Explorer haalde ik zo'n 7 uur uit m'n tablet, met chrome ongeveer 3,5(een Acer iconia w700)

[Luminair]

Eigenlijk vind ik dit heel raar. Chrome en Safari maken allebei gebruik van de WebKit engine. Het enige wat ik kan bedenken is dat Chrome Flash geïntegreerd heeft en Safari functies heeft die Flash uitzetten en er vaak eerst op geklikt moet worden.

[The Milkman]

Blink!

[sjun]

Een andere reden om Chrome niet te gebruiken kan zorg om de eigen privacy zijn.

[Verwijderd]

Bij welke browser moet je dan zijn? Bij IE kan je het ook niet bewijzen. Dan moet je zelf je eigen Chrome of Firefox zelf compileren.

[sjun]

Vooralsnog bevalt Opera uitstekend.

[Yggdrasil]

Ik ben gestopt met Chrome op mijn Macbook Pro omdat die constant de aparte GPU gebruikt i.p.v. de energiezuinige versie die in de processor zit.

Voor bepaalde sites snap ik dat, maar voor het merendeel van de sites is de geïntegreerde GPU snel genoeg. Dat kost dus onnodig veel energie. Safari blijkt daar veel efficiënter mee om te gaan.

Doe ik dan iets verkeerd, of is dat nou eenmaal een eigenschap van Chrome?

[Reactie gewijzigd door Yggdrasil op 23 juli 2024 05:37]

[sfranken]

Gelukkig kun je dit sinds Chrome ~33 uitzetten:

Ga naar chrome://flags (sorry, hier stond settings maar dat is niet goed) en zoek naar 'GPU compositing on all pages' en zet dit uit. Herstart je browser en klaar. Bron: http://www.sevenforums.co...cceleration-turn-off.html

[Reactie gewijzigd door sfranken op 23 juli 2024 05:37]

[Blizz]

Die optie is opgesplitst in verschillende andere opties. Maar het zou niet uit moeten maken: setting 1, teleurstellend resultaat 1.

Het probleem ligt erbij dat Chrome buggy werkt op Macs met twee GPU's en dat Google dit letterlijk niet wilt oplossen en sinds 2012 het probleem bij Apple legt. Het enige programma ter wereld dat dit niet wilt oplossen is een programma van het gigantische softwarebedrijf Google. Raar dat Firefox dit wel kan. Google omzeilt hun bug op door de discrete GPU te forceren, zelfs als GPU acceleratie uitstaat.

[sfranken]

Sorry, ik had de verkeerde chrome-internal link gepost. Het moet "chrome://flags" zijn, daar kun je GPU compositing helemaal uitzetten. Dan zou je probleem over moeten zijn.

Over je 2e alinea, tjsa, een beetje flamebait is het wel he?
1) De hotfix die jij linkt is precies dat, een hotfix. Zoals in die post ook is uitgelegd moet het HW-detectiesysteem van Chrome worden aangepast om op Apple H/W een dual-GPU te kunnen detecteren. Als Apple niet over de brug komt met info hoe hun OS dit kenbaar maakt (in /dev/<hw> ergens misschien?) word het voor elke software bouwer lastig om zoiets te fixen. Bovendien haal je een bug report naar boven op OS X 10.7.x, wat een oudere versie is. Heb je bewijs dat het op 10.8/10.9 nog steeds is?

[Blizz]

Ik was naar flats, maar die staan op default en worden IIRC overruled als je die algemene instelling uitzet.

Ik run 10.9 met de nieuwste stabiele versie van Chrome. Naar die bug report wordt in de browser zelf verwezen. Bij chrome://gpu staat nml. deze regel onder Problems Detected:
Force to use discrete GPU on older MacBookPro models: 113703
Applied Workarounds: force_discrete_gpu

Twee jaar later heeft zelfs Dropbox het probleem opgelost. Mozilla weet hoe het werkt. Voor Google is het echter te lastig? Geloof ik niet, zo wel dan ligt het probleem bij hun software en moeten ze Chrome herschrijven.

[Blizz]

Dit is een nare eigenschap van Chrome.

[Coffee]

Eigenlijk had ik dit eerder verwacht, aangezien macs al bijna 9 jaar 64 bit processors hebben (en al bijna 7 jaar volledig 64 bit hardware draaien, op een paar producten na).

Maar ja, dat chrome nu pas 64 bit draait is o.a. de reden dat ik geswitched ben naar safari, veel lagere memory footprint, minder energie verbruik. Daar tegen overstaat verminderde functionaliteit t.o.v. Chrome.

Misschien is het tijd chrome weer op te starten en te kijken of het nu beter draait.

[ppl]

Sinds 2007 hebben Macs een 64 bit processor (de Core 2 Duo). Daarvoor was het beperkt tot de G5 die alleen in de Powermac zat. Het is hoogstens 7 jaar en niet 9 jaar. Hoogstens omdat de Core2Duo Macs nou lang niet allemaal volledig 64 bit zijn. Er zijn een aantal met een 32 bit EFI. Eigenlijk is alleen de hardware die Mavericks kan draaien volledig 64 bit.

[lukjah]

Dan nog, geen reden om pas 5 jaar na linux een 64 bits voor osx uit te brengen.

[tcviper]

Zo zijn ze bij Google eindelijk eens wakker? Werd toch even tijd zeg...
De 32-bit versie was vooral super sloom bij het opstarten en gebruikte inderdaad veel meer power. Tot nu toe ziet het eruit dat deze nieuwe versie een stuk minder verbruikt. Hopelijk fixen ze wel de GUI bugs die ik nu al zie (settings menu bijv). Maar in Yosemite zie ik ook de HOME knop die constant wijzigt als je met muis erover heen gaat.

[Reactie gewijzigd door tcviper op 23 juli 2024 05:37]

[Mikemkm]

Geen GUI problemen hier hoor

[tcviper]

Ik draai Yosemite, misschien dat dat het dan is?

[Mikemkm]

Wellicht, gebruik zelf 10.9.4

[gjmi]

Yosemite is nog in béta, dus daar kunnen ook nog problemen in zitten.

[Phntm]

Hoe lang zal het duren voordat de 64 bit uitkomt op de stable-channel voor iedereen?

[Rafe]

Chrome brengt elke 6 weken een nieuwe versie uit, en versie 37 is eergisteren uitgekomen

[DexterDee]

Waarschijnlijk zal de 64-bit Java plugin op deze versie wel gewoon werken, dan zijn we gelukkig van dat gezeur af

[Deddiekoel]

Daar denkt de Sun Oracle site iig nog anders over.

[Maurits van Baerle]

Hoezo? Er bestaat geen 32 bit Java op OS X dus Oracle moest waarschuwen dat Java niet werkte op Chrome. Nu Chrome eindelijk ook 64 bit is mag je aannemen dat het gewoon werkt.

Why can't I use Chrome with Java 7 on my Mac?
Chrome is a 32-bit browser. A 64-bit browser (Safari or Firefox, for example) is required to run Java 7 on Mac OS X. 32-bit browsers such as Chrome do not support Java 7 on the Mac platform.

https://www.java.com/en/download/faq/java_mac.xml#sysreq

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 05:37]

[gjmi]

Als ik het artikel lees moeten alle 64-bit browsers Java 7 gebruiken en chrome deed dat niet. Dus het ligt niet aan Java voor OSX. Andere 64bit software gebruikt ook al Java. Chrome liep gewoon achter omdat het de nieuwe Java niet ondersteunde.

[Reactie gewijzigd door gjmi op 23 juli 2024 05:37]

[CyBeR]

Chrome liep achter omdat 't een 32-bit-only binary was, en de java meuk in OSX al een paar jaar 64-bit-only is. Dat is niet compatibel.

Nu komt Chrome met, vermoedelijk, een universal binary en kun je dus ook java in Chrome gebruiken (in theorie allicht, niet geverifieerd.)

[Gamebuster]

Joepie, ik ga meteen updaten! ...owja, ik gebruik geen Chrome op OS X omdat-ie mijn accu in no-time leegtrekt terwijl Safari gewoon relaxt draait.

[Dreamvoid]

Ik hoop vooral dat ze de font rendering fixen, sinds Chrome 36>37 eergisteren is het ineens afschuwelijk lelijk geworden op de Mac. Geen idee wat ze precies aan het doen zijn, maar het ziet er niet uit.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 05:37]

[RPAngelov]

De energieverbruik van Chrome is goed genoeg natuurlijk draait IExplorer onder Windows beter - het is een product van Microsoft die in hun eigen OS geintegreerd is. Zelfde geval ook bij Safari

[Amiga3000]

Chrome wordt steeds slechter, op mijn android toestel is het gewoon niet meer te draaien.
Op de pc vreet het al het geheugen op.
Sandboxen zijn een hele woestijn geworden