Plán pro Firefox 3.6

Vydání Firefoxu 3.5 se blíží a s tím se objevují plány na další verzi. Ta je zatím označena jako 3.6 (což se ale může změnit) a vyvíjena bude pod názvem "Namoroka". Vývojáři se chtějí zaměřit mimo jiné na zvýšení výkonu aplikace samotné (její spouštění, otevírání nových tabů a podobně) a snazší personalizaci --- například "lehké" addony, které lze instalovat bez nutnosti restartovat prohlížeč. Více informací naleznete na wiki.mozilla.org

7.4.2009 11:54 | Tomáš Heger (geckon) | Zajímavý článek

Komentáře

[shadius]

a uz to konečně pojede pod linuxem stejně rychle jako pod widlema? protože linuxova verze je jedna velka tragedie co se tyce rychlosti

[Grunt]

A přestane už někdy konečně to skučení, protože to je IHMO ta největší tragédie linuxových verzí.

[Peter H.]

Zaujímavé je, že čím sú výkonnejšie počítače, tým sa ľudia viac sťažujú na pomalosť. Ja mám Fx 3.0 na relatívnej "šunke" a so zobrazovaním stránok obyčajne nemám problém. Rozdiel oproti Windows na tom istom počítači nie je nijako priepastný.

Jediná tragédia je rýchlosť štartu.

[kyknos]

zrejme zalezi na tom, kolik a jake stranky prohlizis. Firefox je s nekterymi weby na hranici nebo dokonce za hranici pouzitelnosti :)

[AsciiWolf]

Hm, pro GNU/Linux je k dispozici 64bit verze flashe, firefoxu i java pluginu, kdežto pro Windows jen 32bit, takže ty vaše kecy o "pomalosti ff pod linuxem" jsou v dnešní době, kdy člověk nesežene 32bit procesor, trochu mimo...

ps. Na 32bit strojích mi firefox připadal stejně rychlý pod oběma OS (Linux,Windows)...

[shadius]

nechapu jak souvisi 64bit verze FF a pluginu pro nej s rychlosti startu a nacitani stranky, rozdily mezi 32bit a 64bit jsou vetsinou naprosto mizive...mam 64bit kubuntu, FF standartne z repozitaru a rychlost FF napriklad oproti Opere nebo Konqueroru je na mem NTB (dual core, 2GB RAM) naprosto priserna, a co vic i FF na virtualizovanych XPckach mi prisel radove sviznejsi nez linuxova verze, coz uz je docela podezrele nemyslite? zejmena prohledavani historie navstivenych stranek je zoufale pomale (tusim ze je to resene pres nejakou interni SQLite databazi), na druhou stranu mi to zase nepada jako Opera a s flashem (se kterym byl/je obecne na 64bit linuxovych strojich docela problem) take vcelku bez problemu... tohle neni zadny pokus o flame, ale jenom moje poznatky z praktickeho pouzivani, takze si prosim odpustte ty reci o "kecech", protoze tim ten FF nijak nezrychlite a tudiz muj nazor nijak nevyvratite, snad vim s cim pracuji ne? ;)

[aR]

Potvrzuju, že na stejném HW je rozdíl ve prospěch Win. Nevím čím to je (moje specializace je úplně jiným směrem), výsledek je prostě takový, že načítání trvá na linuxu moc dlouho.  A to je škoda.

[M!ky8]

Krome dlouheho startu se mi taky se mi casto stavalo (jeste na nejakem Celeronu 2,6GHz, 512MB RAM) ze casto vytuhlo GUI,  nevim jak by to bylo na soucasnem HW, presel jsem k Opere. Pod Windows (i ta virtualizace) to je precejen bohuzel rychlejsi

[juzna]

Taky jsem zjistil ze Virtualbox s WinXP a firefox v nem je o hodne sviznejsi nez mit spusteny FF primo v KDE.

Nova beta (3.5b) se mi ale zda stejne svizna na linuxu jako 3.0 na win (3.5b jsem na win nezkousel).

[Nicky726]

Ještě že nepoužívám Firefox

[Salamek]

taky to boužel musím potvrdit, verze na win je mnohem svižnější a to i na několikanásobně horších strojích , jak v startovací době ,tak ve scrolování (stačí trocha flashe , nebo obsáhlejší stránka a FF mi při scrolování zamrzá )

[Tomáš]

nemůže rychlost souviset s tím, že windoze mají defaultně zapnuto cachování DNS?

Mám na linuxu spuštěný cache DNS server a proti windoze (vista ultimate) na stejném stroji v dualbootu mi to nepřijde o tolik tragičtější. Je pravda, že mám "pomalý" počítač (AthlonXP 1700+/1GB RAM), tak se mi to může zdát relativní. Musím ještě dodat, že na linuxu mi ještě běží lokální squd, na windoze nic takového.

[default]

No, já si myslím, že nejdůležitější je počet překladů. Rozroste se nějak? Nevíte?

[Ladicek]

Určitě. Z důvěryhodného zdroje jsem slyšel, že přední český odborník na překlad produktů Mozilla připravuje překlad do klingonštiny

[mmm]

V přípravě je chodština a brněnský hantec.

[Kingskid]

Na domácím kompu mám dual boot a moje zkušenost s FF pod oběma systémy (WXP a Ubuntu 8.10) je taková, že doma raději zapínám WXP, protože scrollování FF pod Linuxem mi pomalu vypíná počítač.

[bhy]

a nebude to něčím úplně jiným? ovladače grafiky?

[kapo]

Taky muzete zkusit ve FF vypnout "jemne strankovani". To je opravdu desne chciple...

[J. M.]

Tak co se týče scrollování, žekl bych, že jsou na tom jiné linuxové prohlížeče ještě mnohem hůře (Opera v nové Qt 4 verzi), ale hlavně je na Linuxu šíleně líné celé GUI Firefoxu. Různá menu ani nestíhají následovat kurzor myší, když jimi projíždím, otevírání okýnek a dialogů vždyky následuje až po důkladném „zamyšlení“ se, nelze moc otevírat více stránek současně, protože to celý Firefox na dlouhou dobu kompletně vytuhne, jako by vůbec nepoužíval vlákna nebo co. Obcně pak každá interakce s linuxovým Firefoxem (vstup z klávesnice nebo myši) má šílenou režii, hodně vytěžuje procesor. O rychlosti překreslování třeba při změně velikosti okna nemluvě. Oproti windowsové verzi zkrátka šílený rozdíl. Ale tak je to v Linuxu se vším. Opera, Flash, jEdit... Prostě GUI na Linuxu je velký problém.

[vlastikroot]

Proste GUI na linuxu pro closed source (nebo molochy jako firefox) vyuzivajici GTK vselijakymi zpusoby misto toho aby rozvijeli/pouzivaly KDE ktere je prijatelne rychle i na starsich pocitacich. Porovnani konqueroru z kde3 a firefoxu, beziciho na stejnem pc, firefox na widlich a konqueror pod coLinuxem nad Xming serverem je taky pekna ukazka toho, jak vselijak narocny firefox a cele gecko je.

[Grunt]

GTK, gecko, KDE

To je furt dokola. Jako důkaz že tomu tak není doporučuji vyzkoušet Epiphany(či jiný Gecko prohlížeč krom FireFoxu) Midori či Chromium.

[vlastikroot]

Epiphany se mi jevi naprosto stejne pomale jako firefox, az na to ze toho umi min. Proti GTK jako takovemu vicemene nic nemam, sam pouzivam nektere vysoce kvalitni GTK programy (napr. pidgin). Webkitove prohlizece jako Midori jsou docela prijatelne (napr. pro mobilni zarizeni, midori bezi dobre i na freerunneru). Jako referencni platformu beru celeron 366MHz, kde uz to neni rozdil v radu milisekund, ale desitek sekund, Firefox i epiphany se tam pousti minutu a pri pokusu o zadani adresy se pismenka objevuji nekolik sekund po zmacknuti tlacitka. Takhle si to opravdu nepredstavuju, hlavne kdyz konqueror z KDE tam bezi dobre (asi jen o trochu hur nez IE6 z w2k).

[Grunt]

Epiphany se mi jevi naprosto stejne pomale jako firefox, az na to ze toho umi min.

To se mi nezdá. Neříkám, že je to zrovna jako Chromium ale je docela robustní.

pri pokusu o zadani adresy se pismenka objevuji nekolik sekund po zmacknuti tlacitka

Problémy realtime vyhledávání v tom adresním řádku(a nejen v něm) je problém specifický pro Epiphany. Krom toho, že do adresního řádku nacpali progress bar věřím, že už to dávno zpravili.

[J. M.]

Epiphany se mi jevi naprosto stejne pomale jako firefox, az na to ze toho umi min.

GUI Epihpany je řádově rychlejší. To je snadno objektivně měřitelné (např. měřičem vytížení CPU). Právě proto, že to je čisté GTK+, na rozdíl od abstraktního XUL u Firefoxu, které je tou zpomalující vrstvou. Epiphany je svižnější prakticky ve všech pozorovatelných věcech ohledně GUI — otevírání dialogů a oken, otevírání a přepínání karet, rychlost nabídek, režie vstupu (psaní, navigace na stránce klávesovými zkratkami...), vykreslování GUI. Samozřejmě co se týče rychlosti zobrazovacího jádra, tam velké rozdíly nejsou, pokud oba používají Gecko. Ale v rychlosti GUI je rozdíl zásadní.

[Grunt]

Xming

No a o tom nemluvím radši vůbec.

[Deleted [8409]]

Asi uz to tady bylo, ale podle me za to muze Gtk:) Poridil jsem novy komp (Core Quad) a mam pocit, ze vsechny Gtk aplikace na tom jedou nejak divne (ale i KDE4 nic moc). Napriklad kdyz srovnam eclipse vs netbeans tak ten netbeans (ktery pouziva asi swing, je tak?) mi prijde co se tyce GUI o mnoho rychlejsi. Tezko to budu merit nebo nejak dokazovat, to jsou veci, ktere clovek citi pri praci s tou aplikaci.

Co se tyce toho XUL, tak neverim, ze to je ta brzda. Kdyz se pusti firefox pod Wine, tak tam taky jede XUL, ale aplikace je celkove rychlejsi.

Proste smirme se s tim, ze Gtk ma vysokou rezii :)

[bhy]

to by ale nevysvětlovalo, proč je rychlejší GUI epiphany

[Grunt]

A hlavně chromia:

$ ldd `which chromium-browser`
        linux-gate.so.1 =>  (0xb8043000)         
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7f19000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7f0f000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7eff000)      
        librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7ef6000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7b59000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7acd000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7ab1000)        
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7a89000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7a6e000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7a63000)
        libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb79fb000)              
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7988000)                  
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7945000)          
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb78ce000)            
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb78a1000)        
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7863000)      
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb785e000)      
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb77a7000)            
        libnss3.so.1d => /usr/lib/libnss3.so.1d (0xb7686000)                  
        libnssutil3.so.1d => /usr/lib/libnssutil3.so.1d (0xb766d000)          
        libsmime3.so.1d => /usr/lib/libsmime3.so.1d (0xb7647000)              
        libssl3.so.1d => /usr/lib/libssl3.so.1d (0xb7617000)                  
        libplds4.so.0d => /usr/lib/libplds4.so.0d (0xb7613000)                
        libplc4.so.0d => /usr/lib/libplc4.so.0d (0xb760e000)                  
        libnspr4.so.0d => /usr/lib/libnspr4.so.0d (0xb75d8000)                
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb75be000)    
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb75ba000)              
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7594000)                
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb74a6000)                
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7497000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7339000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7335000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb731c000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7319000)
        /lib/ld-linux.so.2 (0xb8029000)
        libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb7315000)
        libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7312000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb730c000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb72f6000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb72f3000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb72e9000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb72e2000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb72d8000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb72be000)
        libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb727c000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7256000)
        libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb7251000)
        libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb7248000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7221000)
        libpcre.so.3 => /lib/libpcre.so.3 (0xb71f7000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb71f2000)

[Deleted [8409]]

To nevim, ale pod Windows je taky XUL a to GUI je rychlejsi, takze jedine co muzem porovnavat je XUL pouzivajici WinAPI (vytez) a XUL pouzivajici Gtk.

Nerikam, ze za vsechno muze Gtk, treba neni brzda firefoxu pouze Gtk, ale rozhodne zde hraje velkou roli.

[Deleted [8409]]

vytez->vitez:)

[default]

No jo. Když on je rozdíl vytěžit a zvítězit.

[Saljack]

Podle mě za to taky může flash. Mě se flash na linuxu furt seká a nejde tak jak má. Ale musím říct, že firefox má v sobě opravdu něco schnilého. Bohužel zatím nemám náhradu. Snad bude brzo už chromium použitelné.

[Grunt]

Přílohy:

• Snímek obrazovky-Getting Around the Chromium Source Code ‎(Chromium Developer Documentation)‎ - Chromium.png (203830 bytů)
• Snímek obrazovky-New Tab - Chromium.png (239116 bytů)

I když je to spíše tak na zprávičku či blog, tak je to 17 hodin co byl vytvořen daily build prohlížeče Chromium, který plně zvládá záložky(otvírání, zavírání), funguje mu address bar,historie,stahování a už se dostalo i na Most visted. I když to vývojáři silně nedoporučují, tak já vás zvu alespoň ke zkoušení, protože do dokončení toho už moc nezbývá. A hlavně až to prohlásí za betu, tak bude potřeba ladit a hlásit bugy. Já mám momentálně už nějakou práci, ale až ji dokončím,  tak mám v plánu se pustit do drátování jádra z prohlížeče Chromium na Epiphany nebo Midori(ten modrý zaoblený hnus se hodí tak leda do KDE). Stahovat binárka či předpřipravené zdrojáky se dají zde.

[Deleted [8409]]

Diky za obrazky,

zajimalo by me, jestli ty taby v budoucnu napasujou do toho titulkoveho pruhu nebo ne :)

[Grunt]

Diky za obrazky

Obrázky jsou na nic. Kdo nezkusí, neuvěří.

zajimalo by me, jestli ty taby v budoucnu napasujou do toho titulkoveho pruhu nebo ne :)

Vlákno vývojářů, které se k tomu vztahuje je zde. Ve zkratce asi s největší pravděpodobností ne, protože v Xkách je to trochu jinak než jak se dělá dekorace ve Winech a tu bolest se nikomu moc nechce pociťovat.

[Deleted [8409]]

Flash mam off :)

Jinak Chromium nevim, prijde mi, ze pod Windows to je celkem zajimavy prohlizec, ale v linuxu by to pro me znamenalo mit jedinou 32bitovou aplikaci v systemu (USE="-multilib")

[default]

Jardík approach?

[Deleted [8409]]

Prece neni nic spatneho na tom mit 64 bit system only:) Neni to tak davno co nebyl 64 bit flash a rekl bych, ze to bylo pro nektere docela peklo :)

[Grunt]

Oficiální vyjádření k tomuto incidentu zde. Abych pravdu řekl, tak to moc nechápu. Nikdo neříká, že nebudou, akorát je to přesunuto hned přímo pod ty taby v dekoraci oken.

[Deleted [8409]]

ja vim, cetl jsem jeste vyjadreni ohledne v8 a moznem portovani na 64 bit, a zda se, ze to zase tak brzo nebude:

> Is it really that hard to make v8 64 bit compliant?

Yes.

(the following is specific to OS X, which I'm working on, but I'm not guessing that Linux or Windows are any less restricted in the respective topics)

First of all, the generated code needs to be of the same arch as the actual generator, which means we need an x86-64 codegen. The x86 codegen can probably form a solid base for this, but it will need a nontrivial amount of work. The reason is that you cannot run both Protected Mode and Long Mode code in a single process on any operating systems I know of, and machine instruction interpretation varies in crucial areas between the two. One of the extra complexities involved in this task is handling the different calling conventions between *NIX and Windows (everybody but Microsoft uses the convention specified by AMD, but guess who has the largest market share).

Second, the V8 code makes some 32-bit specific assumptions: That sizeof(int) == sizeof(void*), that memory allocated by malloc/valloc can be executed directly (in x86-64 it can't; you need to disable the No eXecute bit with mprotect, and when memory is executable, it isn't writable -- at least not on my system (OS X)).

Third, this has implications for garbage collection. V8 manages code and data in the same heaps, but since code needs special handling in x86-64, I can imagine that the garbage collector would need some modification. As mentioned, on amd64 platforms you need to explicitly allow execution of memory blocks, and this permission sytem works on at least a per-page basis, so all blocks of code need to be allocated on a page boundary, which restricts GC flexibility somewhat. If there are ways to circumvent this, I'm not aware of them.

These problems are definitely solveable, but since there's not really any real incentive to do so, I'm doubting that it will happen very soon. :-P

- Simon

zdroj.

Je to tezke no, kdyby s tim od zacatku pocitali, mohli si usetrit hodne prace (v soucasnosti neni ve v8 ani radek pro podporu 64 bitu).

[Grunt]

Myslel jsem si to. Jediný ten bod mi dával největší smysl. No jo, buď můžeme mít věci ohackované a superrychlé a nebo čisté ale pomalé(a žravé). Prozatím můžeme používat čistý WebKit a jeho prohlížeče(Epiphany,Midori,…). Přece jen se to tomu Chromiu téměř vyrovná. A třeba na vanillu budou fungovat i ty patche z Chromium branche.