adva писал(а):
Может есть возможность хотя бы схематично описывать, как сейчас реализовано, и как планируешь сделать?
В условиях ограничения ресурсов хочется побольше сделать
Тем не менее, рассказывать я тоже хочу, поскольку много очень интересного нахожу.
----
План такой. Я постараюсь описывать разворачивающиеся события и, по мере необходимости, буду делать краткие пояснения по матчасти, где это будет необходимо.
Позже перенесу это в свой блог, переоформив в виде законченных статей.
----
ВведениеНачалось все с того, что, в ББ, как и в других программах для Windows, ужасная графика. Связано это, в первую очередь, с тем, что таковы реалии WinAPI. Для получения визуально привлекательного результата штатными средствами Windows нужно очень постараться. До появления GDI+ программирование векторной графики Windows было нетривиальным занятием. Связано это, на мой взгляд, с необходимостью для MS реализовывать универсальное решение. Большинство графических пакетов, вроде Aldus (Adobe) PageMaker, так или иначе использовали собственные графические движки.
Тем не менее, для программ, в которых графика не является основным назначением, выбора не было, приходилось пользоваться WinAPI.
Соответственно, для работы с графикой ББ опирается на WinAPI, конкретнее, на систему GDI.
Как она работает?
(знающие люди могут меня покритиковать, объяснение будет очень схематичным)
Каждое окно в системе имеет т.н. контекст устройства, или device context, он же DC. Можно представить DC как структуру данных, содержащих ссылки на:
* битовую карту окна (она может быть не одна);
* перо для рисования линий;
* кисть для заливок;
* регион отсечения (не обязательно прямоугольный);
* режимы отображения и преобразования координат;
* выбранный шрифт;
* и т.д.
Подробности можно посмотреть
в MSDN.
Конечно, в подавляющем большинстве случаев Windows не дает информацию о внутреннем устройстве своих структур данных, DC не исключение. Поэтому пользователю возвращается дескриптор DC, с помощью которого производятся манипуляции с контекстом.
Можно создавать заэкранные контексты устройств (без привязки к окнам), равно как и заэкранные битовые карты.
Вернемся к ББ.
Для целей работы с графикой подсистема HostPorts реализует операции с битовыми картами. Причем, эти битовые карты могут как быть связаны с окнами, там и могут быть оделены от окна (заэкранные карты).
Каждому порту сопоставляется контекст устройства (при создании или инициализации), затем все операции уже проводятся на этом контексте устройства. Если контекст устройства связан с окном, то манипуляции на контексте сражу отображаются в окне. Но это не обязательно.
В чем состоит суть тех изменений, которые я провожу?
Я написал библиотеку, которая моделирует контекст устройства. Благодаря простоте набора графических операций в ББ, эта работа относительно несложная.
Итак, с помощью библиотеки AGG я сделал библиотеку, которая реализует операции, за которыми HostPorts обращается к WinAPI, это, например, draw_line или invert_rect. Эти операции производят манипуляции на битовой карте, не связанной с DC. И если в случае с WinAPI все манипуляции с контекстом сразу могут быть отображены на контексте, то в моем случае все сводится копированию битовой карты из памяти на контекст.
Конечно, от WinAPI совсем отказаться не получится, мы же в Windows всё-таки работаем, да это и не нужно. Но фактически все операции сводятся к инициализации собственной битовой карты и последующему копированию ее на DC. В теории все просто
Поэтому текущая работа по подмене HostPorts состоит в том, чтобы заменить процедуры, обращающиеся к WinAPI (и вспомогательные) на собственные и изменить цепочку вызовов, обрабатывающих обновление окна так, чтобы использовалась битовая карта не из контекста устройства.
Большая часть работы свелась к замене одних процедур на другие, однако не все так просто. Основная загвоздка случилась со шрифтами, хотя про шрифты я сделаю отдельную заметку.
Вся эта работа затевалась для того, чтобы сделать графику со сглаживанием и хорошую работу со шрифтами. Поэтому в следующей части немного расскажу про AGG.