Vítám, že se tým Chromia snaží o nějaký vývoj. Bohužel potom přijde zkušenost a setkání s realitou, že jsou hromady bugů, které už několik (často i více než 5) let leží ladem a nikdo je neřeší. Výkon renderingu HTML/CSS + pár animací pomocí JS v Chromiu je i třeba oproti Safari dost tragický. Poměrně triviální věci nejedou 60 natož pak 120 Hz a to ani na počítači typu MacBook Pro s M1 Pro nebo poměrně slušném desktopu s dedikovanou grafikou. Umím si představit, jak někdo v Googlu remcá stejným způsobem jako v Microsoftu: https://twitter.com/cmuratori/status/1522468481135902725 a potom je někdo utře: https://www.youtube.com/watch?v=hxM8QmyZXtg
Kdyby byl v renderingu nějaký bezpečnostní problém, tak to opraví snad během hodin. Když je to prostě jen zbugované, že se to chová divně nebo šíleně pomalé, tak to nikoho netankuje, protože Chromium asi nepíšou lidi zaměření na dobrý grafický výkon nebo s chápáním UX. Nejvtipnější na tom je, že potom celé týmy v Googlu přepisují produkty, aby renderovaly pomocí canvasu/ WebGL a vlastně dělají většinu infrastruktury prohlížeče znovu - protože jiný tým v Googlu, který řeší Chromium/ Chrome není schopný dělat svoji práci.
Trochu jsem to téma nakousl ve vlákně zde: https://twitter.com/KaliszAd/status/1613681429103124480
V reálných aplikacích to obecně pravda prostě není, v microbenchmarku možná. Safari minimálně v renderingu HTML/CSS v řadě ohledů Chrome předežene. Mimochodem ani benchmark není třeba dělat, i nezasvěcený člověk to vidí. Prostě Chrome se seká, Safari v tom samém případě ne. Chrome prostě celou řadu úplně základních optimalizací, které jsou běžné třeba ve hrách nedělá. To co je mimo obrazovku nejspíš stále nějakým způsobem renderuje v celé komplexitě. Takže třeba u aplikací s nekonečným plátnem, když pohnete něčím tak, že to skončí mimo obrazovku, je potřeba prvek explicitně v CSS označit že se nemá zobrazovat. To samotné udělá výrazný rozdíl ve výkonu. Přitom prohlížeč má veškeré informace, aby toto byl schopný udělat taky. To samé s přibližováním a oddalováním obrázků, tam má prohlížeč taky velké rezervy ve výkonu, jako skoro ve všem, co se týče renderování HTML a CSS. I Safari má pořád obrovský potenciál. Vždyť se seká i procházení poměrně statických stránek, např. různých novin. Seká se i YouTube, což je další projekt Googlu, který není schopen udělat dobře. (A to vše na aktuálních strojích za 50+ tisíc Kč!)
Řadu věcí jsme v naší aplikaci byli schopni udělat výrazně výkonnější, protože si je vykreslíme do canvasu a hýbeme tím canvasem místo divem. Není důvod, proč by prohlížeč na backendu nemohl udělat přesně to samé, však on ví, že se div ani CSS toho divu nezměnilo. Taky má velkou výhodu v tom, že si může sáhnout na více jader a GPU mnohem přímočařejším způsobem. Taky na to měli asi 14 let tohle vyřešit.
Chrome/Chromium podporuje více platforem. Paradoxně bych řekl, že pokud je nějaká platforma hlavní, tak to bude Android nebo ChromeOS, což je obojí založené na Linuxu. I tak je ale tento argument z mého pohledu mimo mísu, když je výkon prohlížečů obecně tak tragický. Nepřekvapilo by mě, kdyby bylo možné rendering HTML/CSS zrychlit o řád v obecném případě a dva řády ve specifických případech (třeba pokud by vývojář psal věci určitým doporučeným způsobem).
Ospevuješ Safari, ale:
1. Hovoríš o výkone Apple produktu na Apple systému na Apple HW.
2. Nepozeráš sa vôbec na rozdiely medzi Chrome a Safari, a možno ti poviem že NetScape, ktorý nevie JS, renderuje najrýchlejšie.
3. k bodu 2, áno prirovnal som Safari k NetScape, pretože to nevie niektoré featury HTML, CSS, JS, SVG atď, ktoré už iné prehliadače dávno vedia. (https://twitter.com/Rich_Harris/status/1601281675845308416)
4. Safari má ohromné množstvo bugov takého typu, ktorý výrazne narúšajú developer experience aj user experience. K DX príklad Rich Harris autor Svelte, ktorého git commit messages história je plná "i hate safari with the fire of a thousand suns". ( https://github.com/sveltejs/kit/commit/7943e14858eccfad4cf73ff754f40edc835e1607 )
5. Safari má takýto humus https://twitter.com/jordwalke/status/1355681285717385217
6. Safari je rýchlejšie v niektorých situáciách, ale vie o mnohých situáciách kedy je naopak pomalšie.
Možná to je v tom, že máte železo za 50+. Já mam dva kousky za 16 a cca 20k, používám tedy vivaldi, žere to paměť jak prase (15gb uplně v klidu, ale co si budem, já jsem taky prase a mam otevřenejch 100 záložek), ale že by se mi něco sekalo, to se mi teda nestalo.
Zkuste si taky koupit lenovo za 16k.
Jak v čem. Docela do toho za poslední asi tak rok šlápli, ale i tak mají samozřejmě rezervy. Každopádně jsem vyjmenoval několik příkladů, kde může Chrome (i Safari) dělat mnohem lepší práci.
Třeba aktuální Chrome na Debian Testing s Core i7-1260P s 48GB RAM a jinak nevytíženým systémem zapojeným v dokovací stanici není schopen scrollovat root.cz nebo stránku s ~250 komentáři na Hacker News(!!!) po kompletním načtení a předchozím proscrollování (kdyby náhodou něco dělali líně) bez ztráty snímku. Dokonce jich ztrácí hned několik podle profileru v dev tools a drobná trhnutí jsou i vidět, když víte, na co se zaměřit. Z dev tools není na první pohled jasné, co to způsobuje. Možná už ten snímek není potřeba, spíš to ale způsobuje neschopnost rendering týmu Chromia/ Chromu. I kdyby ty snímky snad nebyly potřeba, tak by bylo dobré to v GUI dev tools označit třeba jinou barvou, jako že to není problém.
Proč nejsme schopní začátkem roku 2023 na železe ze špičky nabídky z konce roku 2022 vykreslit pár čtverců a animací 60x za sekundu? Vždyť počítač na to může vynaložit doslova desítky milionů operací každý snímek jak na CPU, tak GPU, aby to šlo a přesto se to nestane.
Jistě že by se takových věcí našlo víc. Stejně jako by se jich našlo víc v Safari nebo Firefoxu. Rozdíl je v tom, že ve WebKitu/Safari je těch problémů, kdy něco nepodporuje nebo podporuje špatně, podstatně víc než v Gecku nebo Blinku.
To, že nemáte ošetřené výjimky, je chyba vašeho programu. Na co si budete stěžovat příště? Budete nadávat na OS, když vám v programu vypadne výjimka při pokusu o čtení souboru, ke kterému nemáte práva?
Storage s cookies samozřejmě souvisí – uživateli je úplně jedno, jestli si data ukládáte do cookies nebo storage, pořád jsou to data uložená v prohlížeči.
Ale už to není taková zábava, když 2 programy chtějí moc paměti a její součet je větší než fyzická. Sice díky virtuální paměti fungují, ale celé se to dost zpomalí swapováním. Pokud vím, Safari zmražuje vykonávání starých tabů, možná i Edge, ale Chrome ne. Tj jeho paměť se nedá uklidit jednorázově do swapu - furt se v ní musí přehrabovat.
Za prvé, nemusíte to opakovat, já jsem váš komentář vzal na vědomí a ve svých úvahách a komentářích s touto eventualitou počítám.
Za druhé už to není pravda: https://blog.google/products/chrome/new-chrome-features-to-save-battery-and-make-browsing-smoother/
> Ovšem i zmražený tab zůstává pořád v paměti, takže spotřeba paměti se nijak nezmění.
To si úplne v omylu. On totiž nie je zmrazený. Google memory saver reálne neuspáva weby, on je totiž "state-loss-stash" approach, v takom prípade sa pri otvorení uspatého webu robí refresh (buď z cashe na disku, alebo ak nie je k dispozícii tak zo siete, nový load webstránky), v pamäti nezostane nič z VM instancie (heap size je vynulovaný, DOM nodes zmazané, listenery zmazané, etc), reálne sa uchová v pamäti len a len informácie že existuje daná inštancia (tab), aj keď je prázna, s výnimkou pár informácií... URL, linku na cache (na disku), pár flagov a pár určitých informácií, ako aj timestamp kedy bol tab loadnutý a kedy "uspatý". Reálne teda potom taký "uspatý tab" zaberá pár stoviek kB, možno pár jednotiek MB v pamäti, namiesto niekoľko stoviek MB ktoré bežne inak zaberá.
15. 1. 2023, 14:14 editováno autorem komentáře
A to je vec, ktorá ma štve, lebo ak na to stránka nie je pripravená (čo ak si dobre pamätám nie je ani root.cz a ostatné weby Internet Info), tak pri tom refreshi trebárs zmizne zvýraznenie nových príspevkov.
Ono teda viac ma to štve na Edge, kde je ten discarding nastavený nejako agresívnejšie, tak bez "edge:discards" ani ranu...