Работа продолжается. Поскольку я хочу сохранить интерфейсы по возможности нетронутыми, реализация процедуры Rider.MarkRect вылилась в микрорасследование
Во-первых, в процедуре не используется параметр show. Сначала, видимо, хотели использовать одну технику для создания масок, но потом стали использовать голый WinAPI и отказались от этой затеи. Хозяйке на заметку.
Во-вторых, режимы Ports.invert и Ports.hilite обрабатываются одинаково, т.е. выполняется инвертирование заданного прямоугольника.
Но самое интересное — это реализация заливки прямоугольника с помощью шаблонов Ports.dimXX, где XX это {25, 50, 75}.
Пометка прямоугольника реализована с помощью функции WinApi.PatBlt, которая получает на вход прямоугольник и шаблон, а также номер одной из композитных функций, в случае MarkRect это «xor».
Сама по себе идея композитных функций проста — берется три изображения: исходное, шаблон и их функция, и к ним в разном порядке применяются битовые операции. Тема эта в MSDN хоть и раскрыта, но все же весьма туманна. Сначала я пошел по тому же пути. Попытался разобраться, как происходит применение функций и к чему, с тем, чтобы получить тот же функционал, но уже средствами AGG.
На деле оказалось, что композитные функции — такая нетривиальная штука в реализации и в общем виде (как это сделано в AGG) их использовать весьма непросто. Поэтому после двух дней экспериментов я вернулся к тому, что у меня есть битовая карта и я могу напрямую манипулировать битами.
Что имеем?
Имеем битовую карту, о построении изображения на которой в общем случае мы ничего не знаем. Делаю эту пометку специально, поскольку если бы мы могли перестроить изображение по требованию, можно было бы не модифицировать битовую карту, а накладывать поверх изображения маску и, когда нужно убрать пометку (т.е. когда MarkRect вызывается повторно с теми же параметрами), просто перерисовывали бы изображение. Можно сохранять изображение в промежутках, но это требует определенных ресурсов. Кроме того, это не избавляет от того, что изображение может быть модифицировано после наложения маски.
Поэтому я пришел к выводу, что надо пока использовать тот же механизм, что и PatBlt, но немного модифицировать его для получения визуально привлекательного результата.
Это вылилось в такую реализацию.
Инверсия прямоугольника достигается путем инверсии составных частей пикселей исходного изображения, т.е. каждого элемента триады BGR (в Windows используется именно такой порядок следования байт в пикселе).
Для наложения шаблона (маски) используется простой xor по составным частям пикселя, при этом, цвет (компоненты) маски подбираются таким образом, чтобы в результате для исходного черно-белого прямоугольника была сине-фиолетовая заливка разной степени интенсивности.
Повторное применение той же маски к прямоугольнику возвращает цвета измененных пикселей в исходное состояние.
В HostPorts используются 4 маски. Это упомянутые уже dimXX и focusPat, которая представляет собой косую штриховку и используется в модулях HostMechanisms и OleClient.
На стороне ББ из библиотеки AggLib вызываются две функции invert_rect и xor_rect, которые реализуют и реализуют функционал MarkRect. Можно было бы полностью реализовать MarkRect на стороне AggLib, но мне хочется сохранить возможность контролировать цвет(а) масок, поэтому MarkRect переписывается средствами BB.
---
Сейчас все принципиальные вопросы разрешены и я занимаюсь доводкой библиотеки LibAgg до состояния, в котором ее уже можно будет опубликовать. После этого буду делать подмену HostPorts и HostFonts.
В первом модуле от WinAPI осталось, по сути, только вызов копирования битовой карты на HWND, во втором практически ничего, все делается средствами LibAgg.
Перенос LibAgg на другую платформу (ОС) сведется к следующим модификациям:
* изменение порядка следования цветов в пикселе;
* изменение механизма отображения битовой карты на экране (сейчас это делается средствами WinAPI).
Поэтому, принципиально, есть точки роста и для OpenGL, и для SDL, если возникнет такая необходимость.
