Анимация

Основные виды анимации:

1. Аналог CSS, где анимационные команды прописываются непосредственно в коде (ключевой момент — это прямое изменение значений анимации).

2. Определение некоторого преобразования transformation, которое указывает, как одно состояние переходит в другое (например, D3, ключевой момент — transformation содержит конечное состояние).

3. Определение начального и конечного состояний, а также перехода между ними, что позволяет более просто описать переход, не требуя от него содержать конечное состояние, и лучше отделить состояние от перехода.

Изменение данных применяется только к маркерам mark, его механизм основан на D3 data join.

---

Adobe AE анимация

Adobe After Effects использует два типа анимации: сплайновые кривые Bezier и графики свойств. Они не совместимы.

Основной подход заключается в изменениях свойств между ключевыми кадрами.

Общее требование — это однотипность и соответствие значений между кадрами.

Появление и исчезновение объектов тоже являются изменениями свойств.

Графические типы: прямоугольник, сглаженный прямоугольник, эллипс, многоугольник, звезда.

Базовые фигуры могут быть преобразованы в сплайн Bezier, но обратно они уже не будут преобразованы. В сплайне можно добавлять или удалять точки.

---

Есть базовый подход, согласно которому все графические формы могут быть преобразованы в сплайн Bezier, недостающие части дополняются до полной формы через изменения сплайна.

Сплайн Bezier не может точно аппроксимировать некоторые формы, такие как дуга окружности, особенно при больших углах поворота, поэтому используются методы, такие как穷举法.

---

TODO

Проблема области за пределами координатного пространства area gradient.

Поддержка null для Label и LabelAttr.

Интеграция errorlog, требуется обработка: throw, assert, list.single, singleIntersection.

Два основных направления развития:

анимация

деревья и другие структуры данных, реализация treemaps, санки и других типов диаграмм.

---

Похоже, что для массивов должны быть доступны пользовательские callback функции с параметром index, этот подход кажется практичным, не стоит слепо следовать примеру Dart.

Принцип: минимизация концепций и увеличение гибкости, как теоретически, так и практически, гибкость и универсальность должны быть главными целями.

Рассмотреть взаимосвязь декларативных объявлений declaration и трансформаций transformation, D3 считает, что сосредоточие на трансформациях помогает повысить производительность. D3 использует декларативные помощники над трансформациями.

Этот язык называется встроенным доменно-специфическим языком embedded domain-specific language.

На практике важны метки ticks, особенно при масштабировании.

Необходимо ли выделить форму shape и объединить её с geom?

Похоже, что обновители выборки selection updater должны быть модифицированы аналогично обновителям сигналов signal updater.

Сигнал SignalUpdateOp следует внимательно рассмотреть, поскольку многие проблемы скрыты внутри него. Сейчас идея состоит в том, чтобы сохранять значение initialValue и сигнала, если ни одно из операторов не было активировано.

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

Похоже, что null и NaN всё же следует различать.

Требуется система кодирования ECharts.

Графики состоят из вершин vertice и линий segment? См. статью atlas.

Один из ключевых вопросов: чем больше людей работает с системой, тем важнее становится её настраиваемость (например, детали тени, детали пересечения линий). На определённом этапе настраиваемость становится первым приоритетом.

Похоже, что система должна быть "библиотекой графиков", подобно D3, хотя базовая реализация может быть менее сложной. Однако важно усиливать базовые возможности, чтобы обеспечивать более богатую настройку и возможность кастомизации.

Текущий подход является постепенным, сначала добавляется анимация, затем деревья и графы, и в конце оптимизация синтаксиса.

Основное понимание: экспериментальные элементы предназначены для прототипирования исследований авторами, для разработчиков они менее важны (или говорят, удобство переключения между режимами?).

По данным проблем, многоканальная поддержка источников данных является реальной потребностью, Vega также имеет эту функциональность, поэтому её следует реализовать.

Область domain => область представления viewport?

Сигнал signal? Событие event? В Vega они имеют различные значения.

Область значений называется domain, область значений range.

Кривая называется easing.

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

Статьи

Отличия от gg: форма shape

Взаимодействие interaction и анимация animation

Графическая система Flutter служит основой (см. статью d3)

Статья d3 акцентирует внимание на стандартах, сетевом эффекте, и использовании канвы для графических стандартов.

D3 также подчеркивает преимущества декларативного подхода, который позволяет разделить реализацию и описание.

Суть D3 — это отображение данных в DOM.

Цель соединения данных data join — это то, что если постоянные параметры установлены в enter, а динамические — в update, то все изменения можно сделать анимируемыми.

D3 признаёт принцип "не делай это правильно сразу, сделай это правильно".

Хотя ядро очень простое, но он должен решать обычные задачи. Это достигается благодаря модулям.

Графический примитив graphical primitive

D3 использует различные layout для определения различных типов раскладок.

Тестирование должно сравнивать различные варианты, например, D3 сравнивает себя с Flash.

Использование Dart Canvas является преимуществом, аналогичным D3.

Статья tidy data объясняет терминологию данных, обычно она разделяется на числа number и строки string.

AVL разделяет анимацию на более мощный поток stream и более простый encode, что позволяет удовлетворять различные требования, это стоит изучения.

Vega использует преобразование координат для поиска данных в пространстве данных.

Переход

Соединение двух сегментов Bezier, если последняя контрольная точка первого сегмента симметрична первой контрольной точке второго относительно точки соединения, то переход будет плавным.

Названия могут использовать слова с несколькими слогами, но принцип — не оптимизировать слишком рано, пока используется простые слова, до тех пор, пока не возникнет конфликт.

PathSegment -> PathMark -> Mark -> Серия Shape

Текущие правила установки графика — это использование практического подхода, пока это не станет окончательным.

Две методы определения дуги arc, одна подходит для mark, другая для segment.

Классификация путей path используется как основа, добавлены line, circle, sector (polyline рассматривается как polygon без закрытия).

rXX и XX объединены.Все кроме текста и изображений считаются примитивами.

Два основных принципа: не оптимизировать слишком рано и самостоятельно проектировать, не ориентируясь на API Dart, поскольку оно само довольно специфическое и запутанное.

Так как нужны тени shadow и пунктирные линии dash, а graffiti механизмы уже показали, что каждый примитив может иметь свой путь, то примитивы используются на основе пути.

Овал oval всё ещё необходим, потому что нужно гарантировать, что все методы addXX работают, и принципы установки базовых фигур обеспечивают выполнение всех функций пути.

Polygon и polyline не следует различать, поскольку акцентируется на необходимости и простоте. То же самое относится к rect и rrect.

Тени transparentOccluder всегда true, offset для пунктирных линий не нужен, поэтому эти параметры пока не добавляются.

Выбор ветвей, простые случаи пишутся раньше, идентификаторы также устанавливаются таким образом.

Число сторон пути при рисовании не влияет на вычисления bezier и lerp.

Параметры сектора sector остаются в форме start-end (end и sweep — это просто сумма и разница), чтобы соответствовать всей системе, не ограничиваясь Dart. Контрольное движение clockwise всегда true, и arc также использует эту форму определения.

Теперь радиусы start и end равны, поэтому нет необходимости особо обрабатывать внутренние круги, и нет необходимости дополнительно оптимизировать эту ситуацию.

Теперь текст не удовлетворяет требованиям анимации, поэтому требуется функциональность label.

По данным проблемам, автоматическое определение цвета тени работает хорошо, есть запросы на границы border.

Теперь требуется мощная графическая система, которая бы закрепила опыт, поэтому такие вещи, как градиенты и границы, должны быть добавлены в mark.

Функциональность должна быть максимально мощной, например, shadowColor может быть автоматически вычислен, но также может быть установлен, dashOffset также может быть установлен, borderGradient также может быть установлен, gradientBounds также может быть установлен.

Добавление пользовательских MarkStyle, текст следует организовать в уровне text, text и label находятся на разных уровнях, главное отличие — label требует anchor и align для рисования.

В ShapeStyle, поскольку это простые фигуры, большинство параметров рендера не требуется, они устанавливаются по умолчанию, но параметры для пунктирных линий всё равно нужны.

Так как это shape, то fill по умолчанию, наличие stroke определяется strokeColor или strokeGradient, наличие тени определяется elevation, наличие пунктирных линий определяется dash.

Методы интерполяции для свойств mark и связанных параметров создаются для анимации, также известны как lerps, их особенностью является то, что они не принимают null, а вместо этого используют последнее значение.

Перемещение фигур сохраняет одну rotatio, поскольку остальное можно определить через положение или размер, вращение полезно в некоторых случаях, таких как полярные координаты. Поскольку в shape могут быть другие оси, здесь используется rotationAxis.

Paint обычно представляет вызываемую функцию, draw представляет реализацию, это защищённый тип.

Стиль mark следует использовать наследование и generics, текст следует использовать label, высший уровень, более практичный, нет необходимости в двух уровнях.

Так как система mark final, текстовое расположение можно поместить в конструктор, чтобы избежать повторного расположения при каждом paint.

Rotation является частью style сложно, можно понимать как часть, так и не часть. RotationAxis связан с абсолютным положением, поэтому не следует помещать его в style. Если учесть, что rotation находится в style, а axis в mark, это глупо и затрудняет понимание. Если всё помещено вне, то настройка label бесполезна. Это основана на противостоянии высокоуровневых и низкоуровневых API.

В целом следует стремиться к использованию высокоуровневых API, сочетая полноту функциональности и простоту.

По сути, для графиков rotation и axis лучше всего располагаются вне, для label rotation следует помещать в style, поэтому используется такой подход. Для модели image и label (основано на left-top offset, использует anchor system) это объединяется в box.

Параметры стиля следует использовать с опциональными значениями по умолчанию.

Инициализация paintPoint требует сложной инициализации, которую следует выполнять в конструкторе, устанавливая как late.

Boxstyle align может быть пустым, mark должен иметь возможность установки defaultAlign.

Boxmark всегда имеет rotation axis, это anchor+offset, это фактический смещённый anchor, используется не только для вращения.

Длина и ширина изображения должны быть сохранены для дальнейших тестов.

Clip для scene поддерживает только rect.

Scene возможно полностью не требует подклассов, достаточно передать sublayer как параметр.

---Предположительно, инициализация и удаление лучше обрабатывать внутри AES.

Структура дерева, но без смешивания, group является отдельной единицей.

Принцип lerp заключается в том, что все значения должны быть не null, массивы должны иметь одинаковую длину, а вся работа по заполнению выполняется внутри AES.

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

При выполнении lerp группы важно, чтобы все её подэлементы были также структурированы таким же образом; этот процесс происходит в toFrame. Таким образом, toFrame должно быть способно рекурсивно обрабатывать коллекции.

Если невозможно точно совместить, можно просто перейти к to или промежуточному кадру с прозрачностью.

Сейчас mark и clip сцены находятся в одном месте, поэтому можно требовать их одновременного обновления в update.

Анимация возможна при условии, что view не будет rebuild'иться, так что только события могут вызвать анимацию (changeData, resize, gesture).

Было принято решение заменить сообщение о repaint widgets на уведомление graffiti, которое затем уведомляет каждую сцену начать анимацию, где функции сцены вызывают метод animate в виджете.

После setState в Flutter не вызывается didUpdateWidget, поэтому нет необходимости различать animate и repaint, они всегда являются repaint.

Терминология действий между уровнями:

• Изменение сцены называется set, потому что оно не вызывает никаких действий, update может быть неправильно понят.
• После завершения вычислений view уведомляет graffiti, которое затем уведомляет функцию сцены для update.
• После выполнения update сцена вызывает переданный ей функционал для repaint.

Async функции возвращают Future, отличие от void в том, что void не может следовать за await, поэтому следует использовать Future.

Контроллер анимации stop используется для паузы, reset используется для сброса, обычно слушатель добавляется только один раз.

Задержка больше не требуется, interval может выполнять эту роль.Многократное использование setState в одной синхронной операции возможно, поэтому каждый раз, когда в каждой сцене нет анимации, можно вызвать перерисовку (repaint).

Функция lerp PathMark должна быть уже нормализована.

Правила унификации сегментов:

1. Цель — максимальное совпадение тегов.
2. Разделение на группы по move, дополнение осуществляется простым добавлением.
3. Унификация сегментов — меньший дополняет больший, последний служит эталоном, типы должны совпадать.

Сегменты должны начинаться с mov.

Не следует делать end свойством сегмента, поскольку close может создать путаницу. Лучше сделать метод getEnd(), который позволит arc не вычислять его каждый раз.

Приложения правила дополнения:

1. Кортеж короче, поэтому каждый тег должен использоваться, короткий должен быть подмножеством длинного, порядок должен быть сохранён.

Правила для создания пути, который может правильно анимироваться:

1. Первый должен быть move.
2. Теги не должны повторяться, порядок должен быть сохранён, короткий должен быть подмножеством длинного.
3. Обязательно наличие соответствующего тега в контуре.
4. Расположение close должно быть правильным, иначе он станет to. Close должен использоваться только для завершения, иначе могут возникнуть проблемы.