СА
Если это картинка - скачает один раз и положит в кэш. Если видео - продолжит воспроизводить в том же контейнере.
Size: a a a
2021 April 28
O
В случае видео то, что не в поле видимости, просто не отправлятеся (даже если реально рендерится)
СА
Звучит немного глуповато, но да, почему нет? Это явно дешевле, чем гонять видео.
O
Почему дешевле то?)
O
ну всмысле откуда такая уверенность?
O
dlss+хороший современный кодек с адаптивным битрейтом вполне поспорят мне кажется с перепосыланием всей страницы, тоже пожатой конечно.
O
Не говоря о том, что клиентский браузер получится реально тонким и полностью аппаратно ускоренным
O
Вплоть до того, что кодировать можно построчно, для того чтобы эффективнее со скролом работало)
IV
мы уже обсуждали какой крутой https://htmx.org/ ?
СА
Да ну какой dlss, тут нужен просто losless-кодек, умеющий оперировать диффами между кадрами с учётом скролла.
O
dlss позволит разрешение снизить:)
O
тем более его я думаю затащат в том или ином виде в аппаратку в ближайшие несколько лет для всего клиентского оборудования, очень уж соблазнительная идея
O
Кажется да) Но штука крутая, по крайней мере таковой выглядит.
O
Хех, даже у него особенно умиляет приписка про IE11 compatible:)
IV
просто офигенная. пару часов мучений чтобы начать мыслить в другой парадигме, но это того стоит
СА
Я думаю, что кодеки, рассчитанные на живое видео, непригодны для сжатия UI, где всё на прямоугольниках, кривых и однопиксельных полосках. Будет 10/10 шакалов.
O
Не исследовал этот вопрос. Но в целом принципиально же нет проблемы с созданием подобного кодека?)
O
Но кстати шакалов dlss вполне эффективно может чинить. Просто жать лучше в более низком разрешении (больше бит на точку) и апскейлить
СА
Принципиально есть проблема с тем, что он должен быть losseless и уметь ловить скроллы внутри кадра, в том числе частичные (когда скроллится содержимое одного элемента).
СА
Т.е. передавать инфу не только в виде "пиксели с a по b поменялись на такие-то", но и "пиксели с a по b переехали в позицию c".