Evgeny Kulakov, ты ошибаешься. Он полностью ререндерит список в виртуал дом. Именно полностью. При первом запуске лишь добавление в реальный DOM (обновление) происходит дольше. Очевидно почему - во vue.js как никак но всё же оптимизирован алгоритм обновления реального DOM, а вот рендер (функция vue._render) и в том и в другом случае занимает около 30мс.
Можешь сам это проверить с помощью отладчика chrome. Твоя ошибка в том, что ты сравнил всё вместе (рендер в virtual DOM, сравнение, отрисовку браузером), а я говорил именно о рендере в virtual DOM.
Evgeny Kulakov, нет, точно ничего не меняется, список абсолютно статичный, на его основе сделано выч. свойство с самым обычным фильтром. В результате даже добавление всего 1 элемента в список приводит к вычислениям на 2мс+
Evgeny Kulakov, ну это было бы классно, но на практике в виртуальном DOM рендерится новый список, дальше очень долго сверяется со старым и дальше уже вносятся изменения в настоящий DOM. Vue тратит очень много времени на то чтобы понять, что элементы не изменились, а лишь добавились новые.
Evgeny Kulakov, к сожалению vue даже при наличие ключей всё равно рендерит список заново при каждом просчёте. Он экономит ресурсы отрисовщика браузера, но при этом расходует слишком много ресурсов самого js, выполняя абсолютно бесполезные вычисления.
по идее div не должен вызвать, его можно поместить в отдельный слой над скроллингом. Тут как раз дело в том, что как я понял происходит пересчёт всего содержимого скроллинга.
Ну, canvas лежит на фоне, поверх остальной контент. При каждой отрисовке нового кадра canvas происходит перерисовка всего остального (судя по инструменту layers отладчика chrome)
Сергей Соколов: ну логично. 40к - это я имел ввиду, если брать перебор по 200 для каждой из 200 точек. Конечно действительное кол-во рёбер равно 1 + 2 + 3 + ... + (n-1). В вопросе я сильно утрировал. Спасибо за ваш вариант реализации))
Порядок точек к сожалению практически непредсказуемый, то есть любая может в определённый момент стать связанной с любой другой. То есть всё же рёбер будет 40к... хотя связей будет не больше 200 с вероятностью стремящейся к бесконечности... Идея хорошая, но не очень понятно как избежать цикла по всем 40к рёбрам на каждом кадре (даже для выборки по приоритетам).
Ну не то чтобы тормозит, но ищу способы максимально снизить время просчёта кадра, чтобы анимации в остальной части интерфейса не тормозили на слабых устройствах. Сейчас на 4770k один кадр просчитывается и рендерится в среднем от 1 до 2 мс (конкретно тот код, который я прикладывал от 0.1 до 0.6 мс, иногда и до 1.5 мс доходит). В целом анимация не имеет критическую важность, так что я отключаю её когда среднее время просчёта кадра переваливает за 6 мс. По идее происходить это будет разве что на нетбуках.
Можешь сам это проверить с помощью отладчика chrome. Твоя ошибка в том, что ты сравнил всё вместе (рендер в virtual DOM, сравнение, отрисовку браузером), а я говорил именно о рендере в virtual DOM.