News

Проблемы сопряжения SDL с окнами ББ

Added by Иван Кузьмицкий almost 5 years ago

Обрисую контекст ситуации.

Окно SDL предоставляет контекст OpenGL. На этом контексте рендерятся объекты оконного менеджера, а уже в них встроены документные окна ББ. Окна ББ рисуют через фрейм - маппер, посредством OpenGL-бегунков на порте. Но контекст OpenGL один для всех портов внутри окна OpenGL. Стало быть, и система координат у нас единая для всех окон ББ. А это значит, что рисовать внутри окна ББ надо с учётом его текущей позиции внутри окна SDL (или контекста OpenGL, если угодно). Текущая позиция окна легко учитывается с помощью glTranslate, умножением координат примитивов на матрицу трансформации.

Рисование внутри окна ББ происходит в любой момент времени, не только внутри вызова Restore. Например, контейнер может маркировать выделение текста самостоятельно, без Restore. Это значит, что матрицу трансформации необходимо накладывать при отрисовке любого примитива из HostPorts.

Остюда вытекает следующее решение. Оконный менеджер рендерит все свои визуальные объекты, среди которых и слоты-обёртки с внедрёнными в них документными окнами ББ. Для каждого документного окна выделен порт, которому в момент рендера назначается матрица трансформации, учитывающая смещение слота. Ну а бегунки уже применяют эту матрицу при рисовании содержимого документных окон.

Добавлены слои окон

Added by Иван Кузьмицкий almost 5 years ago

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

Меню работает хорошо

Added by Иван Кузьмицкий almost 5 years ago

Меню поддерживается подсистемой Wm. Выводится стандартный набор System\Rsrc\Menus.
Документы открываются в окне только одного типа. Aux и Tool окна ещё не поддерживаются, это задача на ближайшее время.
Архитектура подсистемы Wm более-менее выстроилась. Широко используется шина обратной связи, сквозь контексты (метод Consider), оказалось неожиданно очень удобно.
Оконная подсистема способна открыть любое отображение как окно. Специальное отображение-слот, с подключенным Windows.Window реализуется на уровне хоста. Модули Windows и StdWindows постепенно превращаются в частность, предназначенную для поддержки документных окон. Поведение окон, ранее описанное в HostWindows (а теперь в StdWindows), во многом перекрывается на уровне подсистемы Wm.
Но алгоритмы Windows\StdWindows всё равно будут поддерживаться, чтобы обеспечить эталонное поведение документных окон.

Кнопка закрытия окна работает

Added by Иван Кузьмицкий almost 5 years ago

Сигнал о нажатии проходит от отображения главного окна (ОГО) через обработчик сообщений оконного менеджера (ОМ) и отображение слота в отображение кнопки. Та сигналит контейнеру через свой контекст (метод Consider) о типе своего действия (решение о действии принимает верхний уровень).
После чего ОГО требует от ОМ убрать окно, затем удаляет фрейм слота и перерисовывает сцену.
Как видно, действие закрытия разбито на две части, выполняется на двух уровнях. Причина такого решения в том, что для удаления фрейма слота надо знать фрейм его хоста, а эта информация доступна только в модуле ОГО.

Решены проблемы с памятью

Added by Иван Кузьмицкий almost 5 years ago

Проверка памяти ББ через Kernel.Allocated() и Kernel.Used() показала, что внутри каркаса всё в порядке. А виндовый диспетчер задач показывает постоянное потребление памяти при перетаскивании окон (перетаскивание приводит к принудительному рендеру сцены, а значит и к перерисовке всех объектов).
Методом исключения обнаружил, что в тесселяторе не удалялся дисплейный список после использования.
Ещё при отрисовке окна каждый раз создавался объект шрифта.
На данный момент проблема с потреблением памяти решена.

Артефакт с курсором

Added by Иван Кузьмицкий almost 5 years ago

Это заметно на низких FPS. Пока сцена рендерится, пользователь (при перетаскивании окна) успевает немного сдвинуть мышку, и ОС отрисовывает курсор на новом месте. Это воспринимается как отставание окна от курсора.

Проблема известная: http://www.gamedev.ru/code/forum/?id=124972
и
http://www.gamedev.net/page/resources/_/technical/game-programming/decoupling-the-mouse-pointer-update-from-the-fr-r820

Неустранимое зло. Единственный путь - ускорять рендеринг так, чтобы мышь не успевала отойти на заметное расстояние.

Исследование причин поедания памяти

Added by Иван Кузьмицкий almost 5 years ago

http://redmine.molpit.com/issues/81

Во-первых, память однозначно съедается при вызове f.DrawString, а при рендере текстов таких вызовов очень много.
Во-вторых, дерево фреймов при рендере текстов, например, заметно ест память, хотя и не так много, как при DrawString.

Высокочастотный рендеринг, срабатывающий при перетаскивании окон, наглядно показывает эти проблемы.

1 2 (11-17/17)

Also available in: Atom