Portál AbcLinuxu, 6. května 2025 17:47
Blíží se vydání nové verze (3.5) webového prohlížeče Mozilla Firefox. Co nabídne? Podrobnější nastavení soukromí, vyšší výkon při zpracovávání JavaScriptu nebo třeba novinky v oblasti HTML 5, CSS 3 a DOM.
Koncem dubna vyšla čtvrtá betaverze Firefoxu 3.5, používající renderovací jádro Gecko 1.9.1.
Měl jsem k dispozici Firefox 3.0.10 z repozitářů Ubuntu a noční sestavení páté betaverze Firefoxu 3.5 z repozitáře
http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main
a to na počítači s Ubuntu 9.04, CPU Intel Pentium M (na 1,7 GHz) a 1 GB paměti. Obě verze Firefoxu byly bez doplňků a dat z dřívějška.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090515 Ubuntu/9.04 (jaunty) Shiretoko/3.5b5pre
Dále budou uvedeny některé novinky ve Firefoxu 3.5, více v poznámkách k vydání. Finální verzi lze očekávat začátkem léta.
Z uživatelského hlediska je asi nejpatrnější novinkou možnost prohlížení webových stránek ve zvláštním režimu (Private Browsing Mode), v němž se neukládají cookies, cache, historie navštívených stránek, ani nic dalšího.
Navíc byla přepracována odpovídající sekce v nastavení: Lze si nastavit, zda se má ukládat vše, případně se nemá ukládat nic, nebo si lze vybrat zvláště uchovávání historie stránek, stahování, dat zadaných do formulářů, případně cookies. Také si lze vybrat, zda má napovídání v adresním řádku fungovat na základě informací z hledání, nebo jen ze záložek.
Dialog pro rychlé odstranění uložených informací o prohlížení se také dočkal rozšíření: je možné smazat data z posledních hodin (lze si vybrat), a to v nastavitelném rozsahu.
Pokud Firefox spadne, můžete si ve stávající verzi zvolit otevření stránek otevřených před pádem pouze při znovuspuštění prohlížeče. Nová verze přidává zvláštní stránku s uloženou relací (about:sessionrestore), takže se k ní můžete vrátit až časem.
Přibyla také zvláštní chybová stránka pro chyby certifikátů (about:certerror), jelikož ta stará mohla působit matoucím dojmem.
Dále je možné například procházet odkazy v zobrazení zdrojového kódu.
Nový Firefox stránky vykresluje rychleji, dokáže totiž „předvídat" obsah stránky (speculative parsing).
Zrychlení běhu programu jsem nepozoroval, běží (oproti dřívějšku, aspoň u mě) zcela plynule. Ve výchozím nastavení mi Firefox 3.0 zabral v paměti zhruba 18 MB, betaverze o osm megabajtů více, s rostoucím počtem panelů se rozdíl neměnil. Předpokládám, že do budoucna se to zlepší, ostatně v nové verzi má být spotřeba paměti nižší až o třetinu.
TraceMonkey urychluje interpreter JavaScriptu (SpiderMonkey) překladem do strojového kódu.
Obě verze Firefoxu jsem prohnal benchmarkem jednak z webu Celtic Kane Online a jednak benchmarkem SunSpider. Je vidět, že došlo k docela výraznému zrychlení.
Benchmark z Celtic Kane Online |
Benchmark SunSpider |
Nově jsou podporovány elementy audio a video z HTML 5. Ukázka (případ elementu audio je ekvivalentní):
<video src="http://muj.web.cz/video.ogg" autoplay> Váš prohlížeč nepodporuje element video. </video>
Je také možné uvést video ve více formátech, zvolí se první podporovaný:
<video autoplay> <source src="http://muj.web.cz/video.ogg" type="video/ogg"> <source src="http://muj.web.cz/video.mov"> Váš prohlížeč nepodporuje element video. </video>
Samozřejmě se objevily i příslušné události pro JavaScript.
Další novinkou je možnost nabídnout v CSS použité písmo ke stažení. Webdesignérům se tedy zjednodušuje situace, co se týče kompromisu mezi kompatibilitou a použitím vlastního (atraktivního) písma - tato záležitost je již dlouho podporována v MSIE pro OpenType písma a nyní ji ovládá i Opera 10, Safari 3.1 a Firefox 3.5 (všechny pro OpenType i TrueType písma).
@font-face { font-family: "Moje Pismo"; src: url("http://muj.web.cz/pismo.ttf"); } body { font-family: "Moje Pismo"; }
Samozřejmě přibylo více věcí, například:
To může člověk dělat i teď.
chtěl bych, aby mi ti milí vývojáři přidali dalších 10cvaknutí myší při vstupu na stránku s nepodepsaným certifikátem - to mě totiž děsně baví
taky si rozhodně nikdy nechci přesunout osobní data jako třeba oblíbené nikam jinam než do dokument&settings - to mi rozhodně nedovolte a když tak jedině ať se hrabu v about:config, na tom ujíždím
v linuxu mi rozhodně nedávejte na backspace "stránku zpět" ať si mám s čim hrát
když už se vám povedlo smotat dohromady historii zpět a v před, nešlo by ještě místo dvou tlačítek dát jenom jedno, víc stejně nepotřebuji, nebo víte co, dejte ho pryč úplně
a ta práce se záložkami - jak mi ff vždycky inteligentně nabídne pro novou záložku nějakou podsekci a zaručeně tu co nechci, no holt stále mně udržuje ve střehu a nutí klikat
Mě by spíš bavilo to neustálý překonfigurovávání proxy serverů podle toho, do který sítě se zrovna připojuji.
Ještě lepší! Opravdu unikátní přístup. Jen co je pravda.
OS X má tak zvané Locations, které přesně toto řeší. Všechny aplikace krom Firefoxu se umí podle aktuální location nakonfigurovat, tak já budu kvůli Firefoxu něco programovat a ladit. Zrovna já.
Programů, co na nějaké Locations dlabou, bude mnohem více než těch pár prográmků, co používají knihovny od Apple.
Mimochodem v linuxovém portu Firefoxu je možnost respektovat proměnnou prostředí http_proxy schovaná pod názvem „Systémové nastavení proxy serverů v systému“. V Mac OS X to nefunguje?
Proměnné prostředí a OS X? Tato vychytávka je samozřejmě podporována, ale řeší se přes plist soubor a musí se kvůli jeho změně člověk alespoň "přehlásit". Co se týče Systémové nastavení proxy serverů v systému, tak tomu nerozumím. Přikládám dialog, který mám k dispozici.
Předem upozorňuji, že volba s názvem Auto-detect proxy settings for this network možná něco detekuje, ale proxy servery rozhodně ne.
Proměnné prostředí a OS X?
To byl příklad z Linuxu. Pokud v Mac OS X existuje jediný zprávný způsob – locations, tak bych čekal, že jej Firefox bude používat.
musí se kvůli jeho změně člověk alespoň "přehlásit"
Jistě, kopírování prostředí při fork(2) je jednorázová věc.
Co se týče Systémové nastavení proxy serverů v systému, tak tomu nerozumím. Přikládám dialog, který mám k dispozici.
Aha, v Linuxu tam je ještě jedna volba navíc, ta, kterou vy tam nemáte.
Každopádně poškáldete mozilláckou Bugzillu. Třeba najdete řešení.
Každopádně poškáldete mozilláckou Bugzillu. Třeba najdete řešení.
To jsem udělal. Těch bug tam mají tolik, že jsem raisnul novou a hoši ji promptně zavřeli, že se prý jedná o duplikát. Je fajn, že aspoň někomu se chce ty duplikáty dohledávat.
chtěl bych, aby mi ti milí vývojáři přidali dalších 10cvaknutí myší při vstupu na stránku s nepodepsaným certifikátem - to mě totiž děsně bavíA ještě by mohli úplně odstranit to zaškrtávátko, které jako výchozí hodnotu nabízí přidání certifikátu mezi důvěryhodné. Když je ten certifikát tak nebezpečný, že se kvůli němu musí uživatel uklikat, tak je přece jasné, že má být automaticky přidán mezi důvěryhodné, ne?
A dal jste námět do Bugzilly? Doporučuji přečíst dva vysvětlující příspěvky v blozích vývojářů Firefoxu k certifikátům. Firefox 3 používá několik set milionů uživatelů a žádná tragédie ani konec světa se nekonají.
Tak to si nemusíte ani vzdychat na fórech a dělat ty lepší věci na práci, máte-li tedy nějaké.
Inu, pane Tomeši, jednak mám dojem, že vzdychání na fórech je částí jejich legitimního významu .
A druhak a hlavně, ten příspěvek má smysl v tom, že nás ostatní upozornil na přetrvávající vlastnost FF, kterou já osobně pokládám taky za dost pitomou - způsob zacházení s certifikáty a bezpečnostními funkcemi s nimi spjatými.Takže dík p. Jirsákovi za hlasité "vzdychání" zde na fóru.
Mimochodem, ani já jsem své připomínky do Bugzilly nedal, neumím anglicky tak dobře, aby mi to bylo co platný, zrovna tak, jako vaše odkazy na vysvětlující příspěvky. Nezapomeňte prosím, že ne každý tu anglinu ovládá .
A k věcnému obsahu výhrad - mě nejde o to, že bych zacházení FF s certifikáty pokládal za málo bezpečné. Ne, ale pokládám ho za otravné a pitomé. Mě osobně při mém způsobu práce se sítí většinou použití certifikátů nijak nechrání, ale zato mě občas docela dost otravuje. Uvítal bych kdyby tyto a podobné módní bezpečnostní funkce bylo možno jednoduše konfigurovat a zejména jednoduše vypínat.
Kdyby to lidé opravdu tak hodně chtěli nebo jim to vadilo, upozornili by na to během betaverzí Firefoxu 3 atd. Žádné takové velké ovace jako vy s panem Jirsákem nebyly, podíl Firefoxu (3) neustále roste, takže možná to bude v další verzi provedeno trochu lépe, ale taková tragédie to určitě nebyla.
dám uživateli za sebou asi 3 dialogy, kde musí potvrdit, že opravdu souhlasí se vším, nemůžu do posledního dialogu dát zaškrtávátko "zapamatovat navždy" ve výchozím stavu zaškrtnuté, čímž popřu ty 3 předchozí dialogy.
Nuhehe. Právě jsem pochopil, proč podíl Firefoxu (3) tolik roste.
Už jste ten idiotský argument o počtu uživatelů psával mockrát. Ale to nelze, neboť Firefox si dritvá většina lidí vybrala, protože ho chtějí (je lepší) a stávající jim ani nejde odisntalovat, a tržní podíl mu roste víc než všem ostatním prohlížečům dohromady, a podíl IE dlouhodobě klesá.
Ale to nelze, neboť Firefox si dritvá většina lidí vybralaKe zbytku je zbytečné cokoliv psát, ale aspoň k tomuhle: když správce sítě (nebo třeba firemní politika) rozhodne, že jediný povolený prohlížeč je prohlížeč XY, nedá se moc mluvit o tom, že to uživatelé chtějí. A koncovým prohlížečem může být jak Firefox, tak MSIE (ostatní prohlížeče asi jen zřídka).
Ale už to rozhodnutí je volba nějaké zodpovědné osoby. V časech, kdy měl IE 95 % trhu a velké množství stránek a aplikací jinde ani nefungovalo (nebo špatně), prakticky žádná reálná alternativa nebyla. To je tak jednodcuhý důvod, že byste ho mohl pochopit i vy, pane Jirsáku.
Samotní užvatelé i zodpovědné osoby přecházejí k Firefoxu. V ČR a Evropě už Firefox už Internet Explorer pomalu předbíhá. Určitě jsou vážné důvody, proč lidé od IE utíkají a proč přibývají nejvíce k Firefoxu, přestože si mohou vybrat z ostatních. Opera, Chrome i Safari se propagují docela dost už dlouho, píše se o nich taky dost...
Ale už to rozhodnutí je volba nějaké zodpovědné osoby.
Ano, měl jsem možnost potkat několik lidí, kteří zavedli na poměrně velké množství počítačů Internet Explorer 7, respektive Firefox 2 --- jejich rozhodnutí byla značně problematická (jeden tomu hovno rozuměl, poradil se s externí MS-friendly firmou a nyní trpí stovky uživatelů; jiný byl zase nadšencem ohledně Firefoxu a to neuvážené rozhodnutí mělo negativní následky). Prostě to musí dělat někdo, kdo má rozum a přehled v oboru.
chtěl bych, aby mi ti milí vývojáři přidali dalších 10cvaknutí myší při vstupu na stránku s nepodepsaným certifikátem - to mě totiž děsně bavíJop, to mám taky děsně rád. Nejlepší to je ve škole, kde na některých učebnách FF nemá přístup ke své historii a člověk si musí všechny ty výjimky naklikat znovu.
Nový Firefox stránky vykresluje rychleji, dokáže totiž „předvídat" obsah stránky (speculative parsing).No to bude dílo. Už teď Firefox problémy, když musí v nevhodném místě přerušit parsování kvůli čekání na data. Teď si ten zdroják ještě začne domýšlet...
A nějaký konkrétní argument? Těžko by zařadily novinku tak, aby to pracovalo čtvrt miliardě uživatelů Firefoxu hůře než předtím, to spíše naopak.
No vidíte to. V každém softwaru jsou nějaké chyby už od prvopočátků. Chápu, že některé mohou někdy vadit, ale odkládat kvůli nim vydání jinak poměrně dobrého produktu donekonečna je horší řešení.
defer
? Hlavně že se MSIE vyčítá, že se snaží být chytřejší, než autor webu. Takže FF už také…
Ve svém zápalu jste také klidně mohl zmínit totéž u WebKitu...
...místo aby se tlačilo na tvůrce webů, aby psali kód pořádně.
A když si představím, že takovejhle balast má bejt run-time pro aplikace… No, jsem rád, že dělám "jen" s databází Oracle a s Javou jen na úrovni Java SE.
Pan Jirsák žije v naivní představě, že v době, kdy je drtivá většina webů nevalidních a používá různé obezličky, že se od nich najednou upustí. Kdo chce, dělá weby podle standardů a ladí pro IE už dávno. Kdo nechce, nepřinutí ho ani sympatická myšlenka.
Já myslím, že jsi jen příspěvek pana Jirsáka nepochopil.
defer
, prohlížeč bude vědět, že ve skriptu není žádné document.write()
a může klidně dál parsovat dokument a skript nahrávat na pozadí. Když tam ten atribut není, měl by to být pro prohlížeč signál, že musí s parsováním dokumentu počkat na to, až doběhne skript.
A princip be strict in what you send, but generous in what you receive se zdaleka nepoužívá jenom na webu.On se ten princip ale na webu nepoužívá – tam se používá pouze ta druhá část.
defer
, ale jeho nepřítomnost znamená zákaz spekulace? Připomíná mi to Céčkové modifikátory inline
nebo register
– v dnešní době je překladač chytřejší než programátor, takže se může zařídit líp. Stejně tak prohlížeč má důvod pokračovat v parsování i při nepřítomnosti defer
, protože s největší pravděpodobností na žádné document.write
stejně nenarazí. Ten atribut je zbytečný a nedivím se, že ho nejspíš skoro nikdo nezná.
A ano, prohlížeče se typicky snaží pouze tolerovat co nejširší spektrum vstupů. To má ten důvod, že většinou žádné výstupy neprodukují Ne že bych něco tušil o atributu defer, ale jeho nepřítomnost znamená zákaz spekulace?Ten atribut znamená, že příslušný skript neobsahuje žádné konstrukce, které by měnily přímo zdrojový kód stránky. Nešťastné je, že existuje pouze tato varianta, a nepřítomnost atributu znamená opak – skript zdroják mění. Lepší by bylo mít tři stavy – mění, nemění a nevím/neurčeno. Ale bylo by od autorů prohlížečů mnohem užitečnější domluvit se na nějakém „nestandardním“ atributu, který tohle bude řešit, a ne zavádět do prohlížeče vlastnost, která (byť jen s velmi malou pravděpodobností) způsobí problémy – a autor stránek ji nemůže vypnout.
Připomíná mi to Céčkové modifikátory inline nebo register – v dnešní době je překladač chytřejší než programátor, takže se může zařídit líp. Stejně tak prohlížeč má důvod pokračovat v parsování i při nepřítomnosti defer, protože s největší pravděpodobností na žádné document.write stejně nenarazí. Ten atribut je zbytečný a nedivím se, že ho nejspíš skoro nikdo nezná.Jenže i v tom Céčku má programátor možnost kompilátoru říct, že to má být opravdu tak, jak napíše, ne? Jenže tuhle možnost u prohlížečů autor nemá. Může třeba napsat takový kód, že ve skriptu udělá
document.write("<!--")
a do takto vzniklého komentáře si „schová“ třeba odkazy na plná rozlišení obrázků. Kdo má vypnutý JS, ten je uvidí rovnou, kdo jej má zapnutý, tomu se natáhnou až na požádání. Jenže spekulativní parsování způsobí, že se natáhnou stejně hned. A šlo by vymyslet i horší případ, kdy nejde jenom o to, že se nějaká data tahají zbytečně, ale třeba se špatně odešlou nějaká data na server.
Kdyby těm prohlížečům alespoň bylo možné říci, že tenhle skript opravdu odložit nemůžou (nějaké no-defer
). Sice by ten prohlížeč porušoval standardy, ale alespoň by se s tím dalo něco dělat. Dnes ty prohlížeče ale klidně poruší standardy, neumožní autorovi s tím nic udělat a ještě to vydávají za přednost.
A ano, prohlížeče se typicky snaží pouze tolerovat co nejširší spektrum vstupů. To má ten důvod, že většinou žádné výstupy neprodukujíTam, kde je nějaký vstup, musí být také nějaký předchozí výstup. A tím výstupem samozřejmě není produkt prohlížeče, ale produkt autora webu – ten se stává vstupem pro prohlížeč. A tam vůbec neplatí to pravidlo být striktní v tom, co produkuju na výstupu. A prohlížeče v tomhle HTML kodéry ještě podporují, místo aby je vedly k psaní pořádného kódu. Ale řežou si tím větev sami pod sebou – tahle stále větší podpora smetí v HTML může mít jediný možný závěr.
defer
, což je na hlavu. Nějaké no-defer
, o kterém mluvíte, by se asi v extrémních případech hodilo, ale optimistická strategie zpracování mi tady přijde jako jasná volba.
Souhlasím s tím, že lidi na výstupu příliš striktní nejsou. Teda vůbec. To pravidlo se dá aplikovat jenom na programy; před nějakými desíti lety pravda ty různé FrontPage příliš rozumný kód negenerovaly, ale co jsem slyšel, dnešní nástroje jsou na tom mnohem líp. Lidský faktor, jako v Černobylu Pokud vím, dnes se píše tak, že JavaScript, který modifikuje obsah stránky, se stejně spouští až když je celá stránka zpracována. Tedy by bylo lze narvat všude defer, což je na hlavu.Podívejte se třeba jen na reklamní kódy vkládané na Abíčku, kolikrát tam najdete
document.write
.
Souhlasím s tím, že lidi na výstupu příliš striktní nejsou. Teda vůbec. To pravidlo se dá aplikovat jenom na programy; před nějakými desíti lety pravda ty různé FrontPage příliš rozumný kód negenerovaly, ale co jsem slyšel, dnešní nástroje jsou na tom mnohem líp. Lidský faktor, jako v ČernobyluTo je nesmyslné rozdělení – vždycky někde za tím programem je člověk. Problém je v tom, že prohlížeče se ohánějí umělými testy a předhánějí se, který prohlížeč rychleji v JavaScriptu spočítá π, místo aby do vývojářských nástrojů prohlížeče doplnili vedle „Validate HTML“ také „Validate JavaScript“ a podobné věci.
document.write
, který generuje document.write
Je více než zřejmé, že je tomu právě naopak.
Co třeba zařídit, aby FF každý den nespadnul
nebo aby v youtube nezatěžovala 4 vide 2GHz CPU na 100%...
možná by to lidi přivítali víc než nový inteligentní hovnocuc
Tu mi neda nenapisat vlastnu skusenost. FF mi bezi vkuse aj niekolko tyzdnov (normalneho pouzivania), medzitym (z principu akym Mac OS X aplikacie zvyknu fungovat) FF nevypinam a browser nepada. Urcite nie kazdy den. A ak aj padne, vzdy na stranke, ktora vo velkom pouziva flash - kazdoapdne naozaj vynimocne raz za dva-tri tyzdne.. Cize mozno skus pozriet smerom k adobe. (vypni na chvilu plugin, ako sa zmeni stabilita)
Co třeba zařídit, aby FF každý den nespadnul
A co třeba si zjistit souvislost mezi knihovnou libflashplayer.so
a prohlížečem?
nebo aby v youtube nezatěžovala 4 vide 2GHz CPU na 100%...
Jednoduchá rada: Nepouštěj současně vide čtyři, ale jen jedno.
A co třeba integrovaná podpora přehrávání videa a audia v Ogg Theora/Vorbis? A co zcela nový JavaScript engine výrazně zvyšující rychlost? To jsou podle mě celkem zásadní vlastnosti.
Přesně tak, novinek je hodně a z hlediska číslování i objemu jsou přinejmenším srovnatelné s konkurenčními prohlížeči (IE, Opera, Chrome...).
Rychlejší interpret JS je dneska třeba jako sůlNení. Pro AJAXové obludy je potřeba rychlá manipulace s DOMem, samotný interpret JavaScriptu není to nejkritičtější místo. Jistě, každé zrychlení dobré, ale interpret JS dnes není to hlavní.
To je moc dobře, že jste to zmínil. Každý může přesvědčit, že Firefox/Gecko manipuluje s DOMem nejrychleji.
Proc tedy zrovna v clanku zmineny test DOMu zadne zrychleni oproti 3.0 neprinesl?
Protože to není moc spolehlivý a komplexní test jako ten, který jsem právě odkázal.
A podle ceho se to pozna?
Vuci tomu odkazovanemu mam metodologicke vyhrady... Vubec nezohlednuje, ktera z testovanych operacich se provadeji hodne casto a ktera velmi zridka.
Tak je tam podrobně rozepsané, co se přesně testuje, a lze to snadno porovnat s jinými prohlížeči nebo jinými verzemi téhož prohlížeče. Metodika je známka. Tvůrci Dromaeo postupně vylepšují a jsou otevření připomínkám. Celtic testy jsou zkostnatělé a žádná spolupráce ani vývoj tam neprobíhají už léta.
Další čtení:
http://ejohn.org/blog/javascript-benchmark-quality/
Hm, celý nie. V prvom rade totiž treba interpreter pre ten XUL + JS jazyk a ten asi niekto musel najprv napísať v C/C++. Ale veľká časť určite, zvlášť ak niekto používa dosť rozšírení.
FireFox je v tom repositáři na co?
Ach jo. FireFox 3.6 jsem chtěl napsat.
Sakra, nevím co s FF3.6 udělali, ale při načítání stránek to švihá pomalu stejně rychle jako Chromium.
Příloha - Taková menší blbost, které jsem si všiml u dnešního Buildu Chromia. Dodělali stabilní verzi Chrome pod Windows, tak se asi plně začali věnovat důležitým věcem u Chromiu pod Linuxem.
Podle mých testů před půl měsícem byla rychlost Firefoxu 3.6 většinou rychlejší jen v řádů jednotek procent. Dělal jsi benchmark nebo je to pocit z reálného prohlížení stránek? Kdyžtak budu muset zkusit znovu.
Prostě napíšu adresu, buch do ENTERu a stránka okamžitě bez čekání naskočí stejně tak jak je tomu v Chromiu. Mám tu k dispozici ještě distribuční Epiphany slinkované se starým xulrunnerem a je to viditelný rozdíl. Pro jistotu zkusím přeložit Epiphany s tou novou (beta)verzí xulrunneru.
Mně ty stránky naskočí skoro okamžitě už i ve Firefoxu 3 a ve Firefoxu 3.5 je to většinou jen malý zlomek sekundy.
Srovnáváš na Windows nebo na Linuxu?
Windows. Vím, že u Linuxu to bylo trochu pomalejší, takže pokud se to zrychlilo i tam, tak je to dobře,
pomalu stejně rychle
Funguje někomu video tag ve FF?
Sakra, proč já vždycky musím dostat ten rozbitý?
Už(moje chyba). Ježiš, první video ve video tagu a taková kravina. Co to v tom Novellu fetují za zelené svinstvo? Jinak je ten tag úplná paráda a absolutně jsem to nečekal. Už to jenom dostat na YouTube.
já to taky nečekal ... ten tag je tak jednoduchý .. a to video tak ... no škoda, že v něm nehraje Ernie a Bert ... a že ten linux je v tom klipu takový, nó ... gumový
Tu je na tom IE a Opera lepsie:
Chtěl bych upozornit i na vylepšování kvality Theora kodeku.
Takže chceš popřít, že v tom článku nejsou popsána vylepšení a další vývoj? To si to jako vymyslely z prstu? Určitě tam nějaká vylepšení jsou, někde třeba zase moc ne, ale já spíš upozorňoval na to, že současný stav určitě nezůstane napořád...
Takže chceš popřít, že v tom článku nejsou popsána vylepšení a další vývoj?Ne, ne. To samozřejmě ne. V klidných částech je obraz nepopřetelně ostřejší(viz. příloha). Dokonce jsem stejný trailer přibližně ve stejném čase jako mají na obrazcích zkoušel a můžu to jen potvrdit. Jen říkám, že vše není jen černé a bílé. Prostě takové to freshmousovské rýpnutí. Prostě není dobré na to upozorňovat v tuto dobu, protože by se toho mohl nějaký trol chytnout. Ono přímé porovnávání také není nic moc, protože já beru jen čistě nijak neoptimalizovanou Thusneldu, která se dá ladit velkou spoustou parametrů(viz. Matrixovskou sérii) a ještě v ní není implementováno dost funkcionality.
současný stav určitě nezůstane napořád...Určitě ne. Náprava byla přislíbena. SVN se hýbe každý den.
Theora:
BENCHMARKs: VC: 61.828s VO: 0.024s A: 0.000s Sys: 1.674s = 63.527s
BENCHMARK%: VC: 97.3269% VO: 0.0382% A: 0.0000% Sys: 2.6349% = 100.0000%
Thusnelda:
BENCHMARKs: VC: 53.300s VO: 0.022s A: 0.000s Sys: 1.600s = 54.922s
BENCHMARK%: VC: 97.0475% VO: 0.0396% A: 0.0000% Sys: 2.9130% = 100.0000%
U kódování je rozdíl ještě patrnější.
Nějak těm číslům nerozumím.
Znamená to, že video o délce 150.48 sekund to přehraje za 61 sekund u Theory a 53 sekund u Thusneldy při zatížení procesoru na 100% o 800Mhz na jednom jádře. Tedy u toho vzorku zrychlení o 14%. Zatím nic moc ale je slíbeno zrychlení 1.5x - 4x. Už tak je Theora bezkonkurenčně nejrychlejší kodek(pro srovnán třeba H.264 je jednou tak pomalejší, o ostatních radši ani nemluvím) a pokud se jim to podaří ještě zrychlit… Už bude scházet jenom implementace pro počítání s celými čísly(Vorbis už jednu takovou má) a budu si moct pouštět full HD videa na digitálních hodinkách a nebo na mikrovlnce.
Ještě časy enkódování:
Theora:
real 37m54.701s
user 35m41.386s
sys 0m7.468s
Thusnelda:
real 31m7.201s
user 28m55.748s
sys 0m7.572s
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.