Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 91 reacties

Mozilla wil dat Firefox vanaf eind volgend jaar een nieuwe renderengine heeft. Die engine noemt Mozilla Project Quantum en is gebouwd voor moderne hardware met multicore-processors en het moderne internet, zo claimt de browserbouwer.

Quantum zal diverse elementen lenen van Servo, de renderengine in Mozilla's Browser.html. Het heeft desondanks nog veel onderdelen nodig voor het een volledige renderengine voor Firefox is, schrijft een ontwikkelaar van Mozilla op Medium. Firefox draait nu op Mozilla's eigen Gecko-engine.

De ontwikkelaar noemt geen cijfers, maar zegt dat Project Quantum het browsen sneller moet laten aanvoelen, terwijl het scrollen vloeiender gaat en pagina's onmiddellijk reageren op input. De basis van de nieuwe engine blijft Gecko, maar belangrijke elementen zal Mozilla gaan vervangen.

De nieuwe engine komt in Firefox-versies voor Windows, Linux, macOS en Android. De iOS-versie maakt geen gebruik van een eigen engine door beperkingen in Apples mobiele besturingssysteem. De eerste verbeteringen moeten volgend jaar zichtbaar zijn, zegt Mozilla.

Mozilla Test Pilot. Dat heeft - vooralsnog - niets met Project Quantum te maken

Moderatie-faq Wijzig weergave

Reacties (91)

Ik vind het nog een beetje chaotisch lopen, de verschillende projecten door elkaar heen. Toch ben ik enthousiast over het gebruik van Rust in Firefox! Er was binnen FF het project "Oxidation", het langzaam inbrengen van Rust componenten binnen FF. De browser is namelijk een stuk meer dan alleen de engine!

Als ik het goed begrijp is het zo dat ze (logischerwijs) hiermee zeggen dat simpelweg Gecko omwisselen voor Servo niet gaat werken (omdat er teveel verschil zit in architectuur).

Oxidation gaat in dit geval grotendeels om:
* Url parser
* WebM demuxer
Ik denk dat het ook vooral ligt aan het feit dat het wisselen van engine van de een op de andere dag een enorme achteruitgang in de ervaring levert. Microsoft heeft daar ook een blogpost over gepost met hun overstap van Trident naar EdgeHTML en EdgeHTML was gewoon Trident zonder legacy en een andere naam. MS heeft na de overstap ook maanden gewerkt aan interoperability fixes om de browser terug op pijl te krijgen om vervolgens Edge 12 vrij te geven. Zelfs al was de architectuur hetzelfde, het is zelfs dan niet heel erg evident.
En wat ik begreep van de Firefox contributors hier (zit in Berlijn bij WikiMedia in een hackathon) is dit feitelijk Oxidation.. met een fancy name. Ze gaan inderdaad elementen van Servo in Gecko inbrengen, zoveel als zinvol/werkbaar is. Het zal niet 1 grote stap zijn maar stukje bij stukje.

Goede move, als je het mij vraagt. Maar als er 1 project is wat het risico van full rewrites aan de lijve ondervonden heeft.... ;-) }:O 8)7 :X |:(

Edit: net nog met een van die gasten gepraat. Quantum gaat dus wel een "stapje" verder dan Oxidization: ze gaan de layout en render engine zelf vervangen met die van Servo. Dat is wel zo'n beetje het meest ingrijpende je kunt doen, nou ja, naast de DOM manipulatie zelf I guess. Het schijnt dat de oude Netscapers er het hardst voor aan het pushen zijn, omdat ze van mening zijn dat het project echt tegen een muur aan gaat lopen als er niet een nieuwe basis komt. Net als 'back in the day'...

Het project richt zich voorlopig wel exclusief op desktop (en een beetje laptop) mede omdat de verwachting is dat hoewel Servo sneller is op een multicore er een goede kans is dat het wat meer energie verbruikt. Niet handig op mobile, dus. Ik weet niet of dit bekenend voor de uitspraak in het artikel dat dit ook voor Android is maar ik zou zeggen dat dat wellicht intern ook nog niet helemaal duidelijk is. In elk geval komen de eerste resultaten sowieso pas volgend jaar...

Oh een ander leuk weetje - dit wordt mede gedaan omdat veel ontwikkelaars in Mozilla graag aan en met Rust willen werken ;-)

[Reactie gewijzigd door Superstoned op 29 oktober 2016 13:39]

Vroeger gebruikte ik Firefox voor al mijn taken. Door de traagheid van deze browser ben ik een hele tijd geleden overgestapt op Chrome.
Chrome verbruikt belachelijk veel geheugen.

probeer FF x64 of nog beter Palemoon x64 die zijn echt rap !
Chrome verbruikt belachelijk veel geheugen.
En da's maar goed ook! Wat heb je aan je geheugen als het niet gebruikt wordt? :Y)
Wat als je het niet hebt? Wat als je wat tabs open houdt om te browsen terwijl je compiler bezig is? Ik heb liever niet dat de compiler weggedrukt wordt naar virtual memory.

Applicaties moeten gewoon niet teveel geheugen gebruiken. Gigabytes voor een browser is echt belachelijk.
Applicaties moeten alloceren wat ze nodig hebben en wat er vrij is. Zodra je OS ram nodig heeft voor iets anders kan het vrijgegeven worden. Ik heb liever dat m'n 24GB goed en efficiŽnt gebruikt word dan dat er ~16GB niks aan het doen is
Als applicatie 1 alloceert wat vrij is, kan applicatie 2 dat niet meer. Applicatie 1 weeet niets van applicatie 2, maar het OS kent beide. Geheugen management inclusief vrij geheugen gebruiken als cache is dus wat OS'en al sinds jaar en dag doen.

Als Chrome veel geheugen alloceerd neemt dat niet enkel dat geheugen weg van andere processen, maar verstoort ook het OS in diens capaciteiten om zaken te cachen. Het OS zal zaken van Chrome cachen ook als Chrome dat zelf niet doet. Echter de hiudige opzet van Chrome zorgt ervoor dat jouw andere processen nu niet of minder gecached worden.
Meer GB over om voor andere taken :)?

[Reactie gewijzigd door vali op 28 oktober 2016 09:59]

Als andere taken geheugen nodig hebben dan zal Chrome die vrij maken toch?
Anders zit je daar met ram die niet gebruikt woord wat erg jammer is.
Ik heb natuurlijk liever dat Windows zelf deed...
Ik heb natuurlijk liever dat Windows zelf deed...

Dat doet Windows dan ook. Het gebruikt o.a. ongebruikt geheugen als cache voor programma's en data bestanden. Het is dan beschikbaar voor iedere programma dat het nodig heeft, maar wordt in de tussentijd als cache gebruikt om de disk te ontlasten.

Ook gebruikt Windows het geheugen als buffer voor disk-IO taken waar het moeiteloos honderden megabytes als write bufffer kan gebruiken zonder dat jij er als gebruiker iets van merkt (anders dan ontbrekende disk IO 8-) )

Maar ook dat Windows potentieel programma's naar disk gaat swappen als Chrome veel geheugen 'commit'. Dat vertraagt die andere programma's als je dan terug wisselt.

Als Chrome het geheugen dus niet vrij geeft stoort dat dus met Windows en maakt de rest van het OS en diens programma's trager.
Firefox (niet 64bit of palemoon ) heeft vanaf versie 4 een geheugen lek. Dat krijgen ze er maar niet uit. Na een dagje browsen en met 3 tabs gebruik ik nog steeds 1 Gb aan RAM. Laten ze dat maar eens oplossen
je heb ook systemen waar niet meer geheugen in kan. of een bedrijf die niet zo'n bedrag in alle oudere pc's willen stoppen.....

dan is efficiŽnt programmeren wel een must , ik die te veel dat men denk dan ga je maar upgraden ipv dat er een beter product ontwikkeld word.
Ik gebruik altijd al mijn geheugen, want de Linux kernel cachet dingen in het niet actief gebruikte deel geheugen…
Kan ik beamen. Palemoon 64 (en 32) draaien op mijn (Debian) systemen heel rap. Als Firerfox eenmaal is opgestart ook wel, maar Palemoon is sneller.
Momenteel gebruik ik Slimjet, werkt ook wel lekker op tragere PCs/Laptops.
Maar is de "traagheid" in het renderen of het dynamische deel van de sites (i.e. javascript). Servo is namelijk alleen verantwoordelijk voor het renderen. Veel sites zijn traag door de enorme hoeveelheid aan (vaak onnodige) javascript.
Ik denk dat als Rust (programmeertaal gebruikt voor Servo) zich heeft bewezen in de Render Engine ook de JavaScript interpreter we herschreven gaat worden, wellicht dat daar ook prestatieverbeteringen uit vloeien.

[Reactie gewijzigd door 84hannes op 28 oktober 2016 08:43]

of gebrek aan upload of zelf power van het webservertje ......
Ik zag een presentatie waarin iemand vertelde dat websites vaak lokaal ontwikkeld worden. Een groot javascript, maar ook een plaatje van 20MB is dan in no-time binnengehaald (uitvoeren is een ander verhaal) waardoor de ontwikkelaar niet door heeft dat er geoptimaliseerd moet worden. Ook het binnehalen van 1000 verschillende (kleine) elementen via een eigen http-request gaat redelijk snel zolang de vertraging tussen server en browser onder de 1ms ligt. Maar als een website dan gehost wordt op een webserver met een vertraging van slechts 5ms tot de browser, dan wordt het verschil pijnlijk duidelijk. En inderdaad: daar kan een browser heel weinig aandoen, al helpt meer parallelliseren vermoedelijk wel.
Ook het binnehalen van 1000 verschillende (kleine) elementen via een eigen http-request gaat redelijk snel zolang de vertraging tussen server en browser onder de 1ms ligt. Maar als een website dan gehost wordt op een webserver met een vertraging van slechts 5ms tot de browser, dan wordt het verschil pijnlijk duidelijk.
Eens met je verhaal. Toch is er een techniek die aardig wat vertraging wegneemt bij het laden van veel elementen: SPDY of HTTP/2. Daarmee wordt maar eenmaal een verbinding opgebouwd, en heb je alleen bij het opbouwen van die verbinding de 'lag'.

Natuurlijk zal het altijd vlotter zijn met minder elementen. Optimalisatie blijft daarom nodig.
Chrome is ook niet meer wat het geweest is. Het wŠs ooit een snelle browser maar op de ťťn of andere manier is het nu een lompe machine geworden. Opera (weliswaar gebaseerd op Chromium) voelt een stuk rapper.
Je vind Chromium rapper voelen dan Chrome zelf?
Waar uit merk je dat want ik heb andere ervaringen
Is een stukje gevoel. Opera voelt voor mij aan alle kanten net wat vlotter dan Chrome.
Is Chrome ook niet een key logger van Google? Heb het vermoeden dat alles wat je typt in Chrome rechtstreeks naar Google gaat.
Als dat zo zou zijn, was het allang bekend gemaakt. Als je het over automatisch aanvullen in de adresbalk en dergelijke hebt, dat kan je uitzetten in de instellingen.
Er gaan wel degelijk gegevens naar Google als je Chrome gebruikt. Zo wordt bij iedere installatie bijvoorbeeld een uniek Id gemaakt, .. Er worden nog meer gegevens gestuurd naar Google, maar daar kan je het beste even op Googelen (via Firefox :+).

Firefox blijft erg gemakkelijk in gebruik, er zijn veel add-ons beschikbaar, en dankzij GTK-3 ondersteuning pas het een stuk beter op het Linux omgeving dan bijvoorbeeld Chromium.
Met deze nieuwe engine hoop ik dat FF ook sneller reageert op Android, want daar blijft het vaak schokkerig en traag.
Chrome heeft toch ook gewoon de optie om het systeem thema (en de WM/DE) te gebruiken?
Klopt, maar dat is niet helemaal hetzelfde. De borders en kleuren worden overgenomen, maar het ziet er nog steeds lelijk en incompleet uit.
Gegevens sturen in z'n algemeen naar Google is wat anders dan Chrome die als keylogger fungeert. Mozilla stuurt ook gegevens met Firefox naar zichzelf, wellicht minder dan Google, maar elke keer Google afserveren puur omdat het een ander bedrijf is als Mozilla is onzinnig
https://www.google.com/ch...r/privacy/whitepaper.html

De OmniBar fungeert standaard min of meer als keylogger.
Dus als jij Google vertelt wat ze voor je moeten gaan zoeken ga je later zeuren dat Google dat weet... 8)7
Het gaat erom dat er dus geen adresbalk meer is, alle URL's die je typt, ook half, worden gelogd. Als ik nu.nl type, was dat vroeger geen gekeylogde zoekopdracht maar commando.
Naar mijn ervaring is Chrome licht trager in het opstarten, licht sneller in het gebruik, maar verbruikt veel meer RAM
Naar mijn ervaring is Chrome licht trager in het opstarten, licht sneller in het gebruik, maar verbruikt veel meer RAM
Mijn ervaring is dat het sinds versie 54 wel meevalt met het RAM-gebruik. En dat zie niet alleen tussen de oortjes, maar mijn machine met vele tabs open swapt nu niet meer tegen het einde van de werkdag ;)
Chrome gebruikt bij de laatste versies inderdaad wat minder geheugen, maar nog steeds meer dan FF. Naarmate je meer tabs open hebt staan neemt het verschil toe.
Zelf ben ik een Firefox 64 gebruiker, maar ik test ook vaak op Chrome en dan heb ik toch de indruk dat Chrome een tikkeltje sneller is. Ik ben benieuwd wat de toekomst voor Firefox gaat brengen.
Klopt helemaal, ook mijn ervaring. Vooral veel RAM gebruik van Chrome, zie ook mijn eerdere reactie hier. Op mijn werk is Chrome (en m.n. de rest van de PC) niet vooruit te fikken daardoor (Win 7 met 2 GB geheugen en een Intel i3 uit 2010).

Als hardware geen bepereking is, is Chrome prima, maar omdat ik mijn bookmarks enzo overal hetzelfde wil, gebruik ik altijd Firefox.

[Reactie gewijzigd door Jack Flushell op 28 oktober 2016 08:51]

"maar omdat ik mijn bookmarks enzo overal hetzelfde wil, gebruik ik altijd Firefox."

Dit kan met Chrome ook gewoon, eerste keer aanmelden met je Google account en klaar. Sterker nog, volgens mij heeft Firefox dit toen 'geript' van Chrome (correct me if I'm wrong).
Maar op zijn werk kan die chrome niet gebruiken vanwege de ram ;)
Ik ben vorig jaar overgestapt op Firefox, juist vanwege de snelheid tov Chrome. Chrome is snel, maar op tragere machines met weinig geheugen is Firefox veel sneller... dus op mijn werk. Chrome deed alles extreem vertragen. Ik wil graag een browser waar ik mee kan inloggen met al mijn bookmarks etc, ook op m'n werk en mijn mobiel. Dan valt IE sowieso af.

FF is trouwens sowieso veel sneller geworden de afgelopen jaren.

[Reactie gewijzigd door Jack Flushell op 28 oktober 2016 07:34]

Daar had ik dus ook last van, maar sinds kort weet Chrome het geheugen veel beter te benutten en is het weer wat sneller dan Firefox. Het scheelt niet veel, maar Firefox ziet er daarnaast ook (standaard) wat logger uit dan Chrome. Ik ben dus ook juist, sinds enkele weken, weer overgestapt op Chrome.
Mee eens. Firefox is wel sneller dan vroeger maar 20 tabs openen op Chrome is binnen een paar seconden gepiept en Firefox duurt er veel langer over en bij Firefox kan je de browser nauwelijks gebruiken omdat die bezig met met websites laden.

Ben heel benieuwd of begin 2018 Firefox weer een alternatief kan worden voor mij.
Waarom zou je in 1x 20 tabs willen openen :?
Als je bijvoorbeeld even de Tweakers RSS feed naloopt in de ochtend, en 20 interessante artikel headlines ziet.
8-)
Bijvoorbeeld!

Ik open vaak meerdere sites van bepaald type, gaming, tech, en lees dan relaxed de pagina's/tabs 1 voor 1. Is fijner dan elke pagina apart laden.

Voelt 'efficiŽnter' aan. :)
Ik gebruik het idd een stuk minder. Nu Edge, dan Chrome en voor enkele restjes de Firefox. Voorkeur verandert door de tijd.
Afgelopen week toch maar weer eens Chrome gaan gebruiken, naar mijn idee loopt Firefox na een tijd namelijk stroperig en loopt het geheugen gebruik op. Sterke kant van Chrome is volgens mij het gebruik van meerdere processen waardoor het per tab snel blijft. Firefox gooit alles op ťťn hoop. Hoop dat dit Firefox weer snel gaat maken, maar om hier nou een jaar op te wachten, dan ben ik denk ik al 100% over op Chrome. Gebruikerservaring van Firefox blijf ik wel fijner vinden. Dingen zoals responsive view en toepassing van web developer toolbar en firebug vind ik veel beter en dat maakt het wennen. Stiekem neig ik dus toch weer terug :)
Firefox gebruikt nu ook multi-processing (e10) sinds de laatste versie(s). Het kan zijn dat het geblocked wordt door add-ons, misschien voelde het daardoor wat trager aan.

Klopt, de developer tools vind ik ook erg gemakkelijk, met de ingebouwde tools kom ik prima uit te voeten. :)
Ben ik de enigste die functionaliteit boven absolute performance vind gaan? Het is leuk dat er zoveel nadruk licht op ram en ui snelheid, maar oude bugs b.v. https://bugzilla.mozilla.org/show_bug.cgi?id=888320 blijven jaren liggen.

Het ergste vind ik nog dat veiligheid nog altijd een achtergesteld kind is, zo heeft het ze 6 jaar gekost om OCSP standaard in te schakelen (https://bugzilla.mozilla.org/show_bug.cgi?id=110161).
Als je de pagina doorneemt zie je het volgende staan:

Het oplossen van de bug is afhankelijk van het oplossen van de volgende bugs:
888316 888324 888331 1069609 1280654 1283381 1286182 1301295 1301304 1301306 1301308 1301310 1301312 1306215 1306216 1306217 1310823 1310831 446510 769352 773205 777279 825294 888328 1288591 1289272 1309457 1310587

Het volgende staat in de comments:
This bug is for use as a tracker for the overall progress on the implementation of all date and time related inputs (week, month, etc).

Dus er komt wel wat meer bij kijken dan simpelweg 'een bug'.
Wat een boel mooie woorden. Benieuwd of ze die uiteindelijk ook gaan waarmaken. Als trouw Firefox-gebruiker hoop ik natuurlijk van wel! Firefox heeft om enkele redenen toch mijn eerste voorkeur :)
Naast sneller verwacht ik ook meer stabiliteit en veiligheid met Servo. De gebruikte programmeertaal is vrijwel immuun voor nullpointer exceptions en mogelijk ook minder gevoelig voor buffer overflows.
De laatste jaren enkel Chrome gebruikt, maar daar heb ik de laatste maanden steeds meer onverklaarbare 'err-connection_timeout"'s mee. Dacht eerst dat het ee specifiek probleem was, maar ik zie het op verschillende machines via verschillende internet verbindingen op diverse locaties gebeuren. Een paar weken geleden ben ik daarom voorzichtig eens begonnen om firefox te gaan gebruiken. Tot op heden geen problemen mee.
IE is voor mij in veel gevallen eigenlijk ook prima, maar daar kan ik helaas geen (officieele versie) ublock op installeren.
In elk geval ga ik met goede moed firefox eens een tijdje gebruiken en zie ik verbeteringen uiteraard ook met plezier tegemoet.
ben benieuwd, wel denk ik dat veel traagheid van FF,, mensen zouden hun FF eens moeten resetten naar stock en dan alleen behoedzaam extensies toevoegen en wie dat nog niet gedaan heeft de X64 gaan gebruiken is echt beter dan de x86, en Palemoon x64 is helemaal rap en stabiel doordat ze veel hele oude protocollen overboord gegooid hebben.
Hopelijk komt dit ook binnen niet al te lange tijd na desktop-release ook in de Android client! Daar heb ik het nog het meeste last van hoe de browser zich gedraagt - Firefox lijkt het gevoel niet te kunnen nabootsen van vloeiendheid en snelheid qua input met bijvoorbeeld Chrome/andere WebKit browsers. Op de desktop zelf kan ik niet echt zeggen dat Firefox zo traag aan voelt. Wel is te merken dat CSS-animaties/JavaScript gegoochel met meer horten en stoten lopen (frameskipping), waar dat bij Chrome niet of minder het geval is.
Ik heb de laatste tijd het probleem dat Firefox nogal vaak blijft hangen met enkele vastgepinde tabbladen. Nu weet ik niet direct of dit aan Gecko/Firefox ligt, maar het is echt storend. Hopelijk lost dit wat op, ben benieuwd of het een grote verbetering zal zijn. Is er al bekend welke exacte versie de eerste aanpassingen moet bevatten (daar we al een release datum hebben voor de eerste alpha in 2018 lijkt me deze vraag niet zo vreemd)?

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True