Векторный стилевой класс

[ddr 2]

    Задумался о применении векторных изображений в стилях контролов. На примере TButton, т.е. создать векторный "стилевой" класс по аналогичный с растровым TButtonStyleObject, 
где для 4-х визуальных представлений будет использовать не TBitmapLinks, а TPath. 

Минусы:

• Не будет 9parts, а значит только фиксированное соотношение сторон;
•  Не родное решение (ниже Сомнение№2); 

Плюсы:

• Самый очевидный - один стиль с 4-мя картинками, вместо в много раз(10+) больше картинок под разные scale/разрешений экрана/размеров....(в зависимости от выбронного способа избавления от "мыла" для работы приложения на любых экранах и мониторах с любым разрешением и scale);
•  Меньшая ресурсоёмкость. Будет шустрее работать (как минимум НЕ медленне), что не критично для Windows, но актуально для  большей части комьюнити данного форума, разработчиков под мобильные платформы. Только за счет отказа от 9parts, быстродействие отрисовки вырастет. См. реализацию TCustomStyleObject.DoDrawToCanvas -9 частей отрисовываются всегда(9 вызовов Canvas.DrawBitmap(...)), даже если они фактически не используются. Я, к примеру, 9parts использую только у стиля листбокса, который "внутри" комбобокса. В остальных случаях, дефакто - 1 область + 8 областей нулевой площади. При желении, даже у листбокса можно отказаться от 9parts. Время загрузки Стиля- (+/-)10% по сравнению к растровому решению.

Сомнения:

1. Поизучав FMX.Styles.Objects.pas "легкой" реализации, что бы, что-нибудь наследовать и пару строк дописать, я не нашёл. Для меня понятное решение, это полностью скопировать(взять за основу "векторных" стиливых классов) TCustomStyleObject и TButtonStyleObject и править... Это 1500+ строк кода. Зная свой темп работы, я для себя переписывание и отладку оцениваю в 2-е недели работы.
2. А потом выйдет 10.4.3 или если сильно повезет, то переставать работать "векторный" класс будет лишь на каждом втором релизе и... goto п.1

ПРЕДЛАГАЮ ОБСУДИТЬ + И - ТАКОГО РЕШЕНИЯ, РЕАЛИЗАЦИЮ,  ЦЕЛЕСООБРАЗНОСТЬ, АЛЬТЕРНАТИВЫ.

[krapotkin]

Вот ровно с этого все и начиналось.  Классно же, любое разрешение, вектор, четкость.

А потом выяснилось, что видеосистема  выводит на экран одну картинку даже с масштабированием примерно раз в 100 быстрее, чем парсит описание SVG и рассчитывает точки каждый раз заново для любого отрезка на экране.

И остались только битмапные стили

[qz5]

Вообще в других фреймворках для этого используют например Lottie. Он позволяет сделать векторные, красивые, даже анимированные элементы, но в своем JSON формате.

Я для Вас даже нашел гитхаб, в котором кажется реализована поддержка его на делфи: https://github.com/HashLoad/lottie-player

Попробуйте перевести SVG в Lottie и потом расскажите.

Так, посмотрел исходники, оказывается он показывает анимацию через показ... TWebBrowser, в котором JS-скрипт показывает Lottie. Грустно.

Есть реализацию Lottie под Андроид, но оно для Java: https://github.com/airbnb/lottie-android

Подключить в Delphi можно, но сложно. Для этого надо сделать по шагам, да и просто уметь:

1. подключить AAR-библиотеки (я пока не умею)

2. сделать обертку java2op (это относительно просто)

3. показать View с анимацией внутри Delphi. Это я не умею, но на этом форуме есть примеры, например подключение View Андроид-камеры:

Как я понимаю, нужно создать нативный Layout через TJNativeLayout.JavaClass.init, создать и в нем расположить View c Lottie,  потом его в определенном месте окна размещать. Но с нативными View тоже много проблем. Например нельзя обычные FM-элементы размещать частично поверх них или полупрозрачно например.