Поддержка аппаратного ускорения в LCL

[MiniQ]

Обсуждается возможность использования средств аппаратного ускорения для отрисовки элементов LCL.
Спонтанное начало обсуждения здесь http://freepascal.ru/forum/viewtopic.php?f=5&t=9710&start=15.
Варианты развития:
1. Qt5 (декларируется использование OpenGL по умолчанию)
2. OpenGL (или библиотеки на его основе, такие как ZenGL, GLUT и пр.)
3. .... (предложите еще варианты)

[Mirage]

Отвечу на пост из той темы тут:

Имхо основная сложность во всей этой затее будет не "гигабайтики" и не тексты-ttfы, а реализовать простой и понятный интерфейс между контролом и гээлем, в смысле хранения-передачи разной "нагрузочной" гээле зависимой информации - контексты, текстуры, вершинные буфера и т.п. Это хозяйство логично хранить вместе с контролом (это ведь его представление в GL контексте), но контролу оно ненужно, нужно только на уровне отрисовки.
Причем так чтоб потом можно было легко сделать например dx (или gdi+ или x11) отрисовку - реализуем саму отрисовку и меняем структуру хранимой с контролом "нагрузочной" информации просто унаследовавшись от соответствующих классов

Я как раз такое уже делал. Именно по схеме слоёв:
1. GUI библиотека, которая ничего не знает о том, как именно она будет визуализироваться. Контролы себя отрисовывают, дергая методы довольно простого интерфейса TScreen - нарисуй квадратик, полигон, текст и т.п. Эту отрисовку можно (и нужно) выделить в еще один слой - для простой поддержки стилей, например. Так сделано в FMX и это её реально сильная сторона.
2. Реализация этого интерфейса через 3D движок. Она даже выводила свойства контролов в редактор движка, чтобы можно было в режиме WYSIWYG редактировать GUI.
3. Подсистема движка, оптимизировано отрисовывающая 2D примитивы и текст.
4. слой взаимодействия с конкретным GAPI.
Никакая специфичная для GAPI выше 4-го слоя не вылезала.
Контрол совсем ничего не знает о GAPI, т.к. теоретически может вообще отрисовываться хоть через canvas. Или консоль.

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

[zub]

Логично, но в моем понимании это выглядит чуток иначе.
Предположим имеем TLabel, на 3 (или на 4?) уровне от TLabela с его кучей пропертей остается уже только матрица трансформации и идентификатор текстуры - больше в общем случае openglю ничего не нужно чтоб нарисовать текстовую строчку растровым шрифтом (ну может еще координаты квада, но неважно). Отрисовали это дело. Что дальше? Забыли матрицу и текстуру? Но из лабела довольно накладно получить это при следующей отрисовке. Вполне логично это дело сохранять между отрисовками и перегенерировать только при изменениях. Где это дело хранить?

[debi12345]

ИМХО, сперва нужно "допилить" нативный LCL-рисовальщик, и уже в нем заменить отрисовку кнопок, списков и т.п.на GL-ю.

[Mirage]

Предположим имеем TLabel, на 3 (или на 4?) уровне от TLabela с его кучей пропертей остается уже только матрица трансформации и идентификатор текстуры - больше в общем случае openglю ничего не нужно чтоб нарисовать текстовую строчку растровым шрифтом (ну может еще координаты квада, но неважно). Отрисовали это дело. Что дальше? Забыли матрицу и текстуру? Но из лабела довольно накладно получить это при следующей отрисовке. Вполне логично это дело сохранять между отрисовками и перегенерировать только при изменениях. Где это дело хранить?

В общем случае хранить в слое, непосредственно занимающемся отрисовкой. Т.е. либо 3, либо 4.
Один из них (какой, зависит от реализации) знает какой набор примитивов требуется отрисовывать. И может сопоставлять с ними матрицы.
Сопоставлять с высокоуровневыми объектами типа TLabel смысла нет, т.к. они могут состоять из нескольких элементов, вложенных друг в друга и т.д. Ну не знает TLabel, что у него там возникнет в процессе отрисовки. Это только отрисовывающий слой знает.

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

ИМХО, сперва нужно "допилить" нативный LCL-рисовальщик, и уже в нем заменить отрисовку кнопок, списков и т.п.на GL-ю.

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

[debi12345]

Кто-то что-то начал делать, не доделал, не факт что оно вообще жизнеспособно, а ты сиди за ним и допиливай.

Зато по ходу можно создать промежуточный слой стандартных рисовальных (линия, строка текста, прямоугольник, дуга,..) методов, которые затем переопределять под нужный бэкэнд - OpenGL, DirectX, OpenCL+OpenCV,..

[zub]

По сути в LCLе нет "нативного" рисовальщика. customdraw жестко завязан на qt (правда я его смотрел давно и краем глаза). Крассическая схема "нарисовал и забыл" в случае GL даст далекий от заявленной производительности результат по обозначеным мной в предидущем посте причинам. И вообще принципы работы различных кустомдрав бакэндов очень отличаются - это нужно учитывать сразу.
Мне очень интересно мнения по этому вопросу, т.к. мой зкад по сути не отличается от дизайнтайм редактора гуя, если смотреть укрупненно. По сути нет разницы что рисовать\редактировать: окружности-полилинии-тексты или буттоны-лабелы-чекбоксы

[debi12345]

Надо определиться какие примитивы аппаратно акселирируемы всеми предполагаемымии бэкэндами (как правило - линии, дуги, прямо- и тре-угольники, поли-линии, заливки, перемещения областей..) - и создать функции для их отрисовки (с кодом, специфичным для каждого бэкэнда), и уже этими функциями, на более высоком (бэкэндо-независимом) уровне абстракции, рисовать GUI-элементы.
То есть как сделано в самом отработанном нативном рисовальщике c несколькими бэкэндами - MSEgui.

[zub]

Я к тому и клоню, что нужно ввести еще слой "низкоуровневых" "контролов":

(как правило - линии, дуги, прямо- и тре-угольники, поли-линии, заливки, перемещения областей..)

т.е.

Контролы себя отрисовывают, дергая методы довольно простого интерфейса TScreen

TScreen выдает на выходе список низкоуровневых "контролов" оптимальных для конкретного бакэнда, и нижние уровни работают уже с этим списком, единожды сгенерированным и перегенерируемым при изменениях контрола.

[MiniQ]

самом отработанном нативном рисовальщике c несколькими бэкэндами - MSEgui

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

PS. Завтра выложу в паблик бекенд под Qt5, тот который альфа, но уже компилится и запускается. Но здается мне, это не то решение, которое бы меня устроило.

[debi12345]

что надо найти время взглянуть, что ж там такого

Есть все.. но недокументированное

[Mirage]

Крассическая схема "нарисовал и забыл" в случае GL даст далекий от заявленной производительности результат по обозначеным мной в предидущем посте причинам.

Если я правильно понял что за схема "нарисовал и забыл", то там с контролем нарисованного скорее проблемы. Кто-то вызвал glClear и все.
Я за схему "запомнил что надо рисовать и рисуй каждый фрейм". Она помедленней, но надежна. И поддается оптимизации.

И вообще принципы работы различных кустомдрав бакэндов очень отличаются - это нужно учитывать сразу.

Меня интересует конкретно бакенд через GAPI.

Я к тому и клоню, что нужно ввести еще слой "низкоуровневых" "контролов":

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

В общем, варианты такие:
1. Делать полностью свой GUI. Без LCL. Типа как MSE.
2. Делать custom-draw backend для LCL.

Я так понимаю, во втором случае работы не меньше, чем в первом. Фактически вариант 1 входит в 2.
У меня есть опыт/наработки по своему GUI (логика, сообщения), по оптимизированному GAPI бакенду для 2D отрисовки вообще и GUI в частности.
Т.е. эти части могу полностью или частично взять на себя, если надо.

Еще будет необходимо сделать враппер сообщений для разных платформ/ОС. Делал это для винды и немного для линуха.
Создание/управление окнами и т.п. тоже сюда входит, как я понимаю.
Какие части еще кто видит и чем готов поучаствовать?

[MiniQ]

Из LCL меня интерисует только привязки контролов (взаимное размещение, отступы).
На всякий случаю еще раз обращаю внимание на уже реализованную простенькую библиотеку под OpenGL.
http://zengl.org/forum/index.php/topic,358.0.html
Реально работающая, все поет и пляшет (правда мне еще нужно будет ее допиливать для линукс на арме)

[Mirage]

У меня тоже есть такая либа, где "все поет и пляшет". Только от таких либ до нормального GUI, который модно использовать в обычных десктоп приложениях, как до луны пешком.
В LCL мне интересна прежде всего возможность запуска уже написанных приложений на новом бакенде. И радость от наблюдаемого повышения качества и производительности.

Кстати, насчет слоя, отвечающего за разметку (размещение) контролов - я сомневаюсь, что у LCL таковой отдельно есть.
Это тоже бакенд должен делать, кто знает?

[debi12345]

Это тоже бакенд должен делать, кто знает?

Это кажется называется "layouter" - их может быть 2+ вариантов (например "pack" и "place" в Tcl/Tk) поэтому ессно никакой не слой, а отдельный контейнерный компонент