Есть проект, где бесконечным скроллом подгружаются элементы картинки, много картинок. Скролл отлично работает в фф/сафари/едже а вот хроме уже после 500 картинок начинает очень значительно лагать. Я пробовал убирать событие скролла(думал в нем дело) - не помогло. пробовал ставить флаг -webkit-transform: translate3d(0,0,0); - немного ускорило, но не значительно. Проект использует бутстрап, уже на него подумываю.. в чем может быть дело?
Скрывать/Показывать картинки которые уже были проскролены.
Например добавлять/удалять класс какой нибудь у которого будет стоять: pointer-events: none;
В количестве элементов. Надо просто удалять старые элементы из DOM. Оставить элементов 30-50, не более. По мере прокрутки невидимые элементы удалять, а новые добавлять.
Александр Таратин: мне по ws приходят уведомления, и нужно некоторые элементы удалять. Если их не будет в dom в этот момент - могут произойти конфликты
Какие еще архитектурные причины? Кривой скроллер - это кривая архитектура скроллера. Быстрый и качественный скроллер - и есть нормальная архитектура. Т.е., никаких архитектурных причин тут нет и быть не может. А какие проблемы-то с удалением? Там просто элементу в метод удаления добавляется проверка: элемент в доме или не в доме - и далее удаляется и пересчитывается индекс или какие-то там дополнительные расчеты и стили. Кроме того, разницы между удалением элемента, когда он есть в доме и когда его нету в доме - нет вообще никакой. Просто когда элемент в доме - он просто будет отсоединен от родительского элемента, а уже потом удален.
Конечно, ведь фф скорее всего делает примерно то же самое - только на уровне своего рендер-движка. Решение - выше. Я таким образом тысячи и десятки тысяч элементов рендерил и все летало с очень плавными анимациями в хроме. Алгоритм примитивнейший - реализуется все очень просто.
Делал очень просто: плавающий фрейм объемом в 3 экрана — предыдущий экран, текущий экран, следующий экран. Контейнеру ставится размер в соответствии с числом элементов. Функция анимации вычисляет новый фрейм в соответствии с текущей прокруткой, затем смотрит, какие элементы есть в контейнере и удаляет лишние и добавляет новые. Лишние - это те, которые выходят за границу фрейма, недостающие - те, которые должны быть во фрейме, но их там нет. А затем корректирует смещение всей группы элементов в контейнере, создавая тем самым анимацию прокрутки и все работает как если бы все элементы были бы в DOM, но по факту в DOM всегда элементов только на три экрана. Именно такой объем элементов для рендера был выбран с целью более быстрой прокрутки и незаметных для пользователя удалений и добавлений.
