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

Обсуждаются как существующие проекты (перевод документации, информационная система и т.п.), так и создание новых.

Модератор: Модераторы

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

Сообщение MiniQ » 03.03.2014 12:44:01

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

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

Сообщение Mirage » 03.03.2014 20:53:31

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


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

Если по теме, то я лично пока не вижу способа вклиниться в LCL со своим модулем ускоренной отрисовки. Если для этого нужно реализовывать туеву хучу других вещей, с отрисовкой ни в малейшей степени не связанных, то это не вариант.
Последний раз редактировалось Mirage 03.03.2014 21:21:26, всего редактировалось 1 раз.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

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

Сообщение zub » 03.03.2014 21:18:33

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

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

Сообщение debi12345 » 03.03.2014 21:26:36

ИМХО, сперва нужно "допилить" нативный LCL-рисовальщик, и уже в нем заменить отрисовку кнопок, списков и т.п.на GL-ю.
Аватара пользователя
debi12345
долгожитель
 
Сообщения: 5752
Зарегистрирован: 10.05.2006 23:41:15
Откуда: Ташкент (Узбекистан)

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

Сообщение Mirage » 03.03.2014 21:37:22

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


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

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

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


Вот как раз этого хочется избежать. Кто-то что-то начал делать, не доделал, не факт что оно вообще жизнеспособно, а ты сиди за ним и допиливай.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

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

Сообщение debi12345 » 03.03.2014 21:43:35

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

Зато по ходу можно создать промежуточный слой стандартных рисовальных (линия, строка текста, прямоугольник, дуга,..) методов, которые затем переопределять под нужный бэкэнд - OpenGL, DirectX, OpenCL+OpenCV,..
Аватара пользователя
debi12345
долгожитель
 
Сообщения: 5752
Зарегистрирован: 10.05.2006 23:41:15
Откуда: Ташкент (Узбекистан)

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

Сообщение zub » 03.03.2014 21:47:46

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

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

Сообщение debi12345 » 03.03.2014 22:01:03

Надо определиться какие примитивы аппаратно акселирируемы всеми предполагаемымии бэкэндами (как правило - линии, дуги, прямо- и тре-угольники, поли-линии, заливки, перемещения областей..) - и создать функции для их отрисовки (с кодом, специфичным для каждого бэкэнда), и уже этими функциями, на более высоком (бэкэндо-независимом) уровне абстракции, рисовать GUI-элементы.
То есть как сделано в самом отработанном нативном рисовальщике c несколькими бэкэндами - MSEgui.
Аватара пользователя
debi12345
долгожитель
 
Сообщения: 5752
Зарегистрирован: 10.05.2006 23:41:15
Откуда: Ташкент (Узбекистан)

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

Сообщение zub » 03.03.2014 22:19:18

Я к тому и клоню, что нужно ввести еще слой "низкоуровневых" "контролов":
(как правило - линии, дуги, прямо- и тре-угольники, поли-линии, заливки, перемещения областей..)

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

TScreen выдает на выходе список низкоуровневых "контролов" оптимальных для конкретного бакэнда, и нижние уровни работают уже с этим списком, единожды сгенерированным и перегенерируемым при изменениях контрола.
zub
долгожитель
 
Сообщения: 2884
Зарегистрирован: 14.11.2005 23:51:26

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

Сообщение MiniQ » 03.03.2014 22:31:45

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

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

PS. Завтра выложу в паблик бекенд под Qt5, тот который альфа, но уже компилится и запускается. Но здается мне, это не то решение, которое бы меня устроило.
MiniQ
новенький
 
Сообщения: 81
Зарегистрирован: 28.01.2013 16:31:55

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

Сообщение debi12345 » 03.03.2014 23:21:19

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

Есть все.. но недокументированное :)
Аватара пользователя
debi12345
долгожитель
 
Сообщения: 5752
Зарегистрирован: 10.05.2006 23:41:15
Откуда: Ташкент (Узбекистан)

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

Сообщение Mirage » 04.03.2014 12:21:01

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


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

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


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

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


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

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

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

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

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

Сообщение MiniQ » 04.03.2014 12:55:21

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

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

Сообщение Mirage » 04.03.2014 19:10:01

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

Кстати, насчет слоя, отвечающего за разметку (размещение) контролов - я сомневаюсь, что у LCL таковой отдельно есть.
Это тоже бакенд должен делать, кто знает?
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

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

Сообщение debi12345 » 04.03.2014 19:33:12

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

Это кажется называется "layouter" - их может быть 2+ вариантов (например "pack" и "place" в Tcl/Tk) поэтому ессно никакой не слой, а отдельный контейнерный компонент :)
Аватара пользователя
debi12345
долгожитель
 
Сообщения: 5752
Зарегистрирован: 10.05.2006 23:41:15
Откуда: Ташкент (Узбекистан)

След.

Вернуться в Разное

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13

Рейтинг@Mail.ru