rulexec / charts Goto Github PK

Сейчас первое состояние миникарты — где-то посередине, заданное... пикселями.

Нужно чтобы первоначальный viewport задавался опциями.

Поток сознания:

В текущий момент X-шкала работает так: при создании графика рисуем две метки по краям, берём максимальную ширину из этих двух, умножаем на полтора, считаем это необходимым пространством для одной метки. Когда знаем ширину — перемещаем метки на свои места (отступ слева и справа от краёв в половину ширины), меняем их текст. Вычисляем доступное пространство между краями этих двух, делим на необходимую ширину для метки, округляем вниз. По этому количеству внутренних меток перерасчитываем отступы, рисуем внутренние. Запоминаем шаг по X между метками.

При изменении viewport'а считаем шаг по X в пикселях, находим максимальную половинную ширину видимой метки, в цикле пока шагВПикселях - максимальнаяПолуширина * 2.5 <= 0 планируем на удаление каждую вторую метку, умножаем шаг по X на два, пересчитываем шаг в пикселях.

По шагВПикселях >= максимальнаяПолуширина * 5 добавляем новые метки между старыми, тоже в цикле, делим шаг по X на два.

После этого всего находим минимальные и максимальные пиксельные X меток, в циклах влево/вправо достраиваем меток до краёв видимой области.

Это довольно примитивно и имеет проблемы с настройкой. Хотелось бы управлять добавлением/удалением меток не какими-то случайными коэффициентами, а желаемыми пиксельными отступами между метками.

Всё на что можно повлиять это:

• Первоначальная генерация (которую можно переделать на более затратную, которая постарается впихнуть сколько сможет, делая несколько попыток).

• Добавление/вставка меток не по сравнению шага с коэффициентами, а по реальным ширинам реальных меток (т.е. нужно будет всегда иметь два соседних уровня, чтобы знать ширины их меток).

• Неравномерный шаг. Когда мы достраиваем метки влево/вправо, мы не обязаны делать это фиксированным шагом (хотя выглядеть это будет как баг). Мы можем сделать несколько попыток, чтобы получить более компактные метки. Выглядеть как баг это будет только при медленном движении туда-обратно, быстрое движение куда-то далеко принесёт больше профита — мы перестроим шкалу на оптимальное состояние «как в первый раз». Можно подшаманить и сделать шаг понемногу стремящимся от текущего к оптимальному.

Второй пункт придётся делать чуть более хитро. Если мы будем полагаться на максимальную ширину текущих видимых меток (плюс какой-то зазор), то нужно ожидать, что в данный момент мы видим самые маленькие метки и в другой области всё будет ровно наоборот. Поэтому придётся либо делать этот зазор больше и забивать, либо менять уровень обратно (что за гранью добра), либо... скейлить забольшие метки, если они превышают допустимый максимум. Возможно, это так же будет резать глаз неоднородностью, поэтому...

У нас есть другая проблема. Если посмотреть на анимацию, то видно, что когда мы смотрим на график первый раз, мы видим практически идеально спозиционированные метки по краям. А после движения/зума туда-сюда — они часто обрезаются границами экрана. Особенно критично обрезание метки справа, грустно, когда ты и так в самом правом положении, а метку не видишь и не можешь на неё никак посмотреть.

... поэтому нужно с какой-то задержкой после окончания движения камеры таки дёргать метки в состояние «как в первый раз». Т.е. мы двинули куда-то график, прошло сколько-то миллисекунд, смотрим, видны ли целиком правые/левые метки, насколько равномерны отступы между метками, насколько пустое пространство между метками отличается от оптимального. И если нам не нравится текущее состояние — перерисовываем метки «как в первый раз» (с анимацией прозрачности, конечно).

С телефона график невозможно скроллить/масштабировать.

@babel/polyfill добавляет 75кб на ровном месте, что бред, ибо код графиков примерно 22кб.

Нужно попробовать не жонглировать кучей <line>, а точками одного <polyline>. Сейчас самая затратная операция при анимации — setAttribute линий, подозреваю, генерировать каждый кадр строку видимых точек и писать в <polyline> будет на порядок быстрее.

Функционал «горячей» замены точек не понадобился и висит в воздухе, ибо в телеграмовском датасете слишком мало точек. Для моих реальных использований эта функциональность нужна, нужно дореализовать.

Нужно подумать, должна ли функция replacePoints быть методом, либо должна автоматически срабатывать по изменению viewport'а, или лучше чтобы линия не знала обо всех доступных точках, а кто-то извне занимался этой генерализацией.