Já s chystanou vlastností budu mít jiný problém: když nad určitý panel najedu kurzorem, vůbec to nemusí znamenat, že se chystám daný panel zobrazit. Mám totiž ouška panelů pod adresním řádkem, takže přes ně občas přejíždím cestou do adresního řádku. S tím Mozilla zjevně nepočítala.
Pokud je otevřete, tak je potřeba je vykreslit tak jako tak. Pokud ne, předpokládám, že Firefox nezačne renderovat jenom na základě přejetí přes ouško, ale i nějakého zpomalení/zastavení kurzoru. Podle předvolby s názvem "browser.tabs.remote.warmup.maxTabs" tam bude navíc nějaké omezení počtu takto přednačtených panelů.
"Pokud je otevřete, tak je potřeba je vykreslit tak jako tak."
To sice jo, ale ale protože zatím nejsou viditelný, stačí stáhnout do cache a ve vlákně s nižší prioritou vygenerovat statickou část stránky. Cokoliv navíc je zatím zabitý výkon.
"Pokud ne, předpokládám, že Firefox nezačne renderovat jenom na základě přejetí přes ouško, ale i nějakého zpomalení/zastavení kurzoru."
Takže když rychle přijedu na taby a na nich zpomalím, abych měl čas je přečíst, tak se začnou pod kurzorem renderovat? Takže když je jich tam několik s dlouhýma nadpisama, něco hledám a zastavím se nad každým kvůli bublině, tak se hned překreslí? A když je jich dlouhá řada, najedu na kraj a projíždím je "za okraj", tak se to celý zbrzdí o načítání a renderování?
"Podle předvolby s názvem "browser.tabs.remote.warmup.maxTabs" tam bude navíc nějaké omezení počtu takto přednačtených panelů."
Aha, takže si nastavím pět panelů jako limit, chci otevřít sedmý, ale pět už se jich bude renderovat zbytečně, šestý ve frontě, z CPU se kouří a já čekám na tab, který chci vidět? Super.
Mně se na tom všem nejvíc líbí ta jejich schizofrenie:
1. Je to pomalé, takže to děláme dopředu
2. Je to tak rychlé, že si nikdo žádného spomalení ani nevšimne
Pokud opravdu stihnou tu stránku vyrenderovat během 2 milisekund, tak vskutku nebude problém s tím, že je začnou renderovat ihned, jak přejedete přes ouško. Ovšem v takovém případě nechápu, proč řeší nějaké renderování dopředu a neudělají prostě přepínání záložky tak, že se nejprve vyrenderuje a pak teprve se na ní přepne.
Spíš oceňuju, jaký mají Mozilláci hluboký znalosti o systému, kde ta jejich splácanina běhá.
Zobrazuje se to na monitoru/displeji. Při refresh rate 75Hz je stejně nejmenší postřehnutelná změna 1/75s = 13,33ms.
Honit v takové situaci 2ms je přece jenom trochu mimo, pokud standardem není monitor s refreshem >= 500Hz... A jenom tak mimochodem, blikání oko vnímá do řádově desítek Hz, takže stejně by to ani nemělo smysl. No a kvůli tomu se dělají takový vopičárny, jako je předrenderování a podobně. Kvůli vykreslení pod 10ms se žere víc CPU a paměti. A dělají se stovky bugů, desítky test casů, navíc... Chápu, dá se na to vykázat činnost, ale to je tak všechno.
Přínos pro uživatele nula, pokud v tom není bug, záporný, když to začne padat.
O takových časech se ale nebavíme. Teď je to přepnutí někde mezi 30 a 40 ms. Ale to nejsou ty nejtučnější stránky typu Facebook apod. https://mzl.la/2rbJjZg
I kdyby prepnuti bylo 100ms, je to uplne jedno, protoze neexistuje na tyhle planete clovek, kterej by to byl schopnej postrehnout.
Vis soudruhu, ze zavodnici sou za reakce do 100ms vylucovany ze zavodu? A to se bavime o reakci na zcela konkretni podnet, na ktery cekaji a soustredi se na nej. V realnym zivote clovek sotva zaznamena zmenu ktera trva 200-300ms.
Na tyhle planete neexistuje ani jedinej clovek, kterej by mel problem s tim, jak rychle browser prepina taby, zato tu existujou miliony lidi, ktery maj problem se spoustou dalsich veci, na ktery chrozila trvale zvysoka sere.
Pro inspiraci se staci podivat tuhle https://html5test.com/results/desktop.html, pri prepoctu na vynalozeny finance/trzni podil zdaleka nejhorsi vubec. Jo jasne, neni cas, je treba presunout taby a udalet je modne sisaty.
Něco postřehnout a zareagovat na to jsou naprosto rozdílné věci. Těch 200 ms je postřehnutelných naprosto v pohodě. https://jsfiddle.net/ojdahrLu/1/ schválně porovnejte 30 a 200 ms.
Podpora HTML5 je fajn, ale zajímá hlavně vývojáře. O html5test.com si myslím svoje. Fajn přehled, ale stejně vás vždycky při vývoji zajímá podpora konkrétních věcí (https://caniuse.com/) a ne skóre, které kombinuje s nějakými vlastními vahami podporu různých věcí z HTML5 a JavaScriptu, ale rozhodně ne všech. Nevím, jak moc si třeba vážíte podpory gamepadu v JS, ale html5test.com třeba dvěma body. Tedy stejně jako plné podpory input type="text". A třeba za validaci vstupního pole s emailem je bodů rovná nula.
Těch 40ms je ale furt jenom 1/25s. Připomínám, že projektory v kině jely na 24fps (41,666ms) a nebyl s plynulostí problém (pokud se pás nezasekával).
Navíc tohle je v podstatě jednorázová záležitost a nevím o nikom, kdo by byl schopný u jednorázové věci postřehnout 20ms zpoždění.
Tady už se řeší rozdíly hluboko pod prahem vnímání člověka. Sorry, ale tahle featura,, pokud něco přinese, bude maximálně mít placebo efekt pro ty, co o ní ví a poslouží k vykázání nějaké činnosti.
2Petr M: Nikolivek, filmy se 24 FPS nataceji, ale promitaji 25 FPS, prave proto, aby divak nevnimal blikani. U starsi produkce (tam kde se zvuk zaznamenaval primo na pas) to samozrejme vedlo k nepatrnymu posunu u zvuku, ale uz par desitek let se zvuk zaznamenava zvlast (pripadne se dela uplne mimo vlastni nataceni obrazu) a tam uz se s timhle pocita => posun neni zadnej.
Těch 40ms je ale furt jenom 1/25s. Připomínám, že projektory v kině jely na 24fps (41,666ms) a nebyl s plynulostí problém (pokud se pás nezasekával).
Mno. Těch 24fps je v podstatě nejmenší možná snímková frekvence, kterou člověk začíná vnímat už jako pohyb a nikoliv jednotlivé obrázky. Tzn níž už to nešlo. Předpokládám, že každý si všimne rozdílu mezi filmem v 30fps a 60fps. To je patrné na první pohled.
Další věc je také v tom, jak ty snímky vypadají. Pokud se točí na dlouhé časy a každý pochyb je na snímku rozmazaný, tak sousední snímky vypadají mnohem více spojitě, než když je každé políčku filmu dokonale ostré. Také i proto vyšší rozlišení potřebuje větší snímkovou frekvenci, aby snímky byly více podobné a mozek si to dokázal spojit.
Navíc tohle je v podstatě jednorázová záležitost a nevím o nikom, kdo by byl schopný u jednorázové věci postřehnout 20ms zpoždění.
Nejde jen o to zpozdění, jde o to, co se tam na těch 20ms zobrazí. Pokud se tam zobrazí prázdná bílá stránka a až přes to se za 20ms vyrenderuje obsah, tak si toho všimne snad každý. Já jsem si toho při přepínání tabů všiml už dávno (ne, že by mě to vadilo).
Tady už se řeší rozdíly hluboko pod prahem vnímání člověka. Sorry, ale tahle featura,, pokud něco přinese, bude maximálně mít placebo efekt pro ty, co o ní ví a poslouží k vykázání nějaké činnosti.
No já bych hlavně ocenil, kdyby to šlo nastavit tak, že každý tab bude předrenderován dopředu a držen v paměti. V podstatě jsem předpokládal, že je tomu tak i nyní. V článku mi trochu chybí zdůvodnění, proč se tato změna zavádí a proč to není vykreslené dopředu. (Ano, dovedu si představit odpověď ve smyslu spotřeba paměti a tak, ale chtělo by to zdůvodnit kolik prostředků by to žralo.)
Na embedded věcech zvládnu obrazovku vyrenredovat třeba za 120ms a není problém, prostě mám dva framebuffery, jeden se zobrazuje a do druhýho se kreslí. Pak jenom přehodím pointery a je to bezrušivýho efektu... fps se řeší až při pohybu a animaci.
Že někdo napřed zobrazuje a až pak kreslí, to je čistě jeho rozhodnutí a hloupost.
2Heron: "V podstatě jsem předpokládal, že je tomu tak i nyní." sak tim jeste nedavno zduvodnovali proc to zere tolik ramky. Jestli ono spis nejde o tom, ze na to nejeti mysi to stranku refreshne, coz je uplne neco jinyho, a jeste mnohem horsiho, protoze tim padem prijdes trebas o vyplnenej formular.
2Petr M: Takhle se snad kreslilo uz v dobach i286 (dokonce uz i na 8mibitech) ne? Ostatne to byl jedinej zpusob jak neco nejak animovat. Prekreslovani obrazu primo bylo extremne pomaly. Kdezto zmena stranky pameti byla hned. Jestli to nekdo nekde dela opacne, tak leda debil, ale nedivim se, sak dneska 99% co se prsi tim ze programuje, vubec netusi jak ty veci fungujou.