Vlákno názorů k článku Má nový formát WebP od Google šanci nahradit JPEG? od vadimo - Kde to zapasuje je Opera Mini alebo Turbo...
-
vadimo (neregistrovaný)
Kde to zapasuje je Opera Mini alebo Turbo mod. To si viem pekne predstavit. Ale neviem si predstaviť záťaž tých serverov. Asi bude väčia ako pri konverzii z jpeg 100% na jpeg 50%. A ak by sa WebP konvertoval do mensej kvality, tak vysledná velkost obrázka by bola minimalna.
Tiež ako obrázok do navigácii a do GoogleEarth. Ja v tom vidím široké použitie, nie len na webe, kde Youtube vysiela vo FullHD to nemá velky zmysel. -
Taky mě to napadlo. Zátěž serveru neumím posoudit. Další otázka u Opery Mini je výkon: implementace bude muset být v Javě (aspoň zpočátku, ale IMHO ještě dlouhou dobu) a výkon různých implementací Javy se liší. Interpret dnes již snad prakticky vymizel, ale i tak tu máme aspoň tři používané implementace: JIT, AOT, Jazelle.
AOT je používáno hlavně v "hloupých" Sony Ericssonech a jde o kompilaci byetcode do nativního kódu (typicky před prvním spuštěním - u SE je zobrazen onen "teplotoměr").
JIT je používáno hlavně na smartphonech. Jde o kompilaci za běhu. Ačkoli nabízí lepší optimalizace (např. brzká vazba u virtuálních metod), ihned po spuštění je výkon obvykle nižší, není-li výsledek JIT cacheován, a to z několika důvodů (verifikace a kompilace).
Jazelle je používáno na mnohých "hloupých" telefonech, typicky S40. (Pravda, některé archaické S40 mají interpret, ale tyto už asi nemají význam.) Jde o HW implementaci, ale patrně není tak výkonná jako AOT a při pohledu na strukturu bytecode jen tak nemůže být výkonnější. Nutnost verifikace při startu zde (narozdíl od AOT) patrně neodpadá a ačkoli některé instrukce (např. invokevirtual) odpovídají více instrukcím strojového kódu, někdy to je naopak (např. kód i++ se do Java bytecode přeloží do tří instrukcí, například aload_1, iinc, astore_1), ale ve strojovém kódu by šlo o jednu instrukci.
ČLÁNKY DO MAILU