OberonCore

как считает честно́й народ: имеет ли мне смысл нежно улучшать растровый bottleneck? давайте признаемся: интерфейс рисовалок в BBCB в своё время был даже выше среднего с его безьерками, но на нынешний день он никакой.

я предлагаю как минимум добавить в bottleneck заливку полигонов и безьерок произвольным паттерном 8x8 пикселей (это нужно, например, для более правильной и полной реализации HostPictures), а также официальный метод создания растровых картинок, манипуляции ними, и разные варианты blit. сами омики, например, в тех же HostPictures вообще плюнули на свои же рисовалки и работали напрямую с винапи. мы — по очевидным причинам — так не можем.

и, кстати, предлагаю рисование овалов из bottleneck выкинуть: это элементарно эмулируется безьерками (ну да, безьерками нельзя рисовать правильные кружочки, но ещё ни один хуманс не заметил разницы). омики скорее всего добавили овалы просто потому что для них было быстрое API, но на нынешний день это малоактуально, я считаю, и лучше bottleneck упростить, оставив только самый минимум.

также предлагаю расширить райдер фрэймов разными утилитарными функциями, типа DrawRoundedRect. там довольно много полезных мелочей можно сделать Просто Один Раз на основе уже существуюшего bottleneck (всё равно по сути всё сводится к рисованию безьерок и полигонов в итоге).

если принципиальных возражений нет (молчание — знак согласия! ;-), я постепенно этим займусь, а потом представлю реализацию, и мы её обсудим/улучшим/переделаем. таким путём удобней, мне кажется, потому что делать bottleneck «от практики» лучше, чем пытаться сначала всё-всё предусмотреть, а потом вспомнить, что в доме забыли запланировать дверь.


на всякий случай (мало ли), если у кого-то из читающих возникнет вопрос, почему нельзя в bottleneck оставить только полигоны, а безьерки унести выше: разное разрешение. райдеры фрэймов работают с универсальными координатами, где DPI порядка десятков, если не сотен тысяч (иногда омики думали ОЧЕНЬ далеко в будущее ;-). если преобразовывать безьерки в полигоны при таком разрешении — получится очень много линий, которые на реальном растре схлопнутся в точки (и выглядеть это будет хуже, чем преобразование с «родным» разрешением). лишняя работа, лишняя память, и никакой пользы. поэтому омики добавили безьерки в bottleneck.


p.s.: кстати сказать, во всех нынешних реализациях портов (начиная с базовой омиковской) есть баг: они абсолютно игнорируют aspect ratio. с этим удаётся убежать только потому, что сейчас почти везде пиксели очень близки к квадратным (но всё равно не квадратные). однако по уму нужно или два юнита (горизонтальный и вертикальный), или как-то учитывать аспект в bottleneck.

1. Не стоит ничего убирать в Port, что бы нарушило обратную совместимость, так что овалы давайте оставим.

2. А что если закодировать паттерны заливки в отрицательном коде толщины линии? (Мы подобное уже сделали в одном проекте для DrawLine, что цвет с отрицательным знаком означает рисовку пунктиром.)

3. Мы как-то обсуждали возможность рисовать текст под углами 90 и 270 градусов. Но после раздумий, есть предложение сделать это через свойства шрифта, то есть кроме добавить vertical, что будет рисовать строку повернутой на 90 градусов против часовой стрелки.

4. Прямоугольник со скруглёнными углами как раз рисуется без проблем кривыми Безье, у меня и код есть такой.

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

паттерны должны быть как минимум битмапами 8x8 пикселей. не хватит байтов. ;-) даже рисовалки dashed lines и pattern-filled lines очень разные по эффектам (поэтому `MarkRect()`, например, использует именно паттерны даже для рамочки в один пиксель толщиной).

мне всё-таки кажется, что это (свойства шрифта) неправильное место: реализация всё равно должна быть в bottleneck, так что более естественно добавить API для такого в райдеры. но тут мне ещё надо подумать и посмотреть.

да, я в курсе. я как раз и предлагаю докинуть во Frame подобных утилит, чтобы не копипастить их каждый раз, когда понадобится: их там не надо будет никуда портировать и поддерживать, просто один раз добавить и забыть навсегда, они будут Просто Работать.

А, я вас понял. Ну тогда надо проверить, что не будет рисоваться хуже по внешнему виду, или медленнее. Проверить и на Windows и на Linux. А так предложение логичное. Сейчас внедрил решения Антона для Windows рисование овалов через GDI+, и коммандер там в Windows сейчас выглядит симпатично. Там правда выяснились проблемы, что GDI+ себя как-то неадекватно ведёт, когда память заканчивается свободная. Тем не менее, сейчас коммандеры лучше выглядят, чем раньше.


Так то лучше сделать кросс-платформенную реализацию через AGG. Тогда не будет зависимости от странного поведения от винды по памяти. Дмитрий Соломенников начинал эту работу, и весьма далеко продвинулся! Я тут выложу всё, что у меня осталось от этой работы. Там не так просто понять, что к чему, но уверен, что вы поймёте ход его мыслей, если будет интересно. Там есть и вызовы самой библиотеки и уже портированный код на КП, без вызовов этой библиотеки.



А надо ли раздувать стандартную графическую библиотеку? Есть некая в Блэкбоксе также эстетика минимализма в интерфейсах.

Про карты 8x8 надо подумать, так как сама реализация StdPictures на постоянной основе сама вызывает сомнения. Эти рисунки хотелось бы перерисовать, так как там странный маковский формат данных. Неясно ни как создавать такие новые рисунки, ни как править старые. Похоже не реставрацию чего-то старого ненужного. Как временная мера сейчас ещё ничего, но даже dim25, dim50, dim75 в документации не обозначены как именно штрихованные, там говориться про оттенки серого цвета.

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

а оно магически станет одинаковым, потому что безьерки BBCB преобразует в полигоны своими силами. ещё один плюс, кстати.

полная AGG в бэкэнде не нужна: там вполне достаточно растеризатора из AGGLite и небольшого кода поддержки. собственно, самописной библиотекой на базе AGGLite я в своих проектах на D пользуюсь давольно давно, и собираюсь её портировать потом. однако замечу, что я весьма прохладно отношусь к самой идее сглаживания: у меня от этого глаза болят. в прямом смысле, физически. это не в смысле что я категорически против, а в смысле что энтузиазма делать AA-рендеринг у меня не так много. в D я это обхожу ручной рихтовкой координат по пиксельной сетке, а в BBCB такое делать некультурно будет (зачем тогда сглаживание, тогда можно намного более простые растеризаторы сделать).

спасибо! я, конечно, посмотрю, потому что очень любопытен. ;-)

ну, совсем уж сильно раздувать я не предлагаю. но всё-таки BBCB — это не только про тексты, так что иметь уже готовые процедуры для рисования тех же прямоугольников со скруглёнными углами и дуг, например, будет полезно, мне кажется. в принципе, было бы неплохо ещё иметь возможность задавать caps и joins для толстых линий, но это я добавлять пока не планирую.

опять же, проблема в том, что делать отдельную рисовалку с кучей возможностей довольно сложно, потому что нет ни стандартной возможности работать с пикселями бэкэнда, ни стандартной возможности создать битмап в памяти, порисовать в нём, и потом битмап блитнуть. и если для тех же caps и joins можно обойтись существующим, то, например, градиенты так уже не сделать. а если захочется вещей покруче, типа масок с произвольным контуром, заливки полноценными изображениями, а не просто паттернами, и прочих вкусных плюшек — то вообще всё печально. и, честно говоря, я не очень представляю, как это решить без раздувания bottleneck'а.

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

проблема с растром в том, что он… ну… растр. а BBCB работает в универсальных координатах, где over 9000 на один реальный пиксел. и каких размеров растры делать тогда? по экрану? по универсалу? от фонаря, и как-то рихтовать?

это я не издеваюсь, это я застрял в попытках придумать нормальный интерфейс для растров.

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

простите, это я пытаюсь быстро-быстро изложить много-много, и получается плохо-плохо. особенно когда смешались несколько понятий. mea maxima culpa.

у BBCB, по сути, два интерфейса к рисовалкам: одна во Frames, в универсальных координатах, и одна в Backend, в пиксельных. безьерки в полигоны — это пиксельная преобразует, и рисует потом полигоны. а с растрами — это как раз проблема того, кому они принадлежат: рисовалке из Frames, или рисовалке из бэкэнда? если второй — то мы теряем возможность, например, нормально распечатать картинку. а если первой, то непонятно, какое у картинки должно быть разрешение, потому что универсальные координаты же, unit очень большой.

вы правы, это надо бы расписать более внятно. я постараюсь.

в общем, расписать словами я так и не созрел, а вот кодом — да. в Lament Configuration реализованы как улучшения портов, так и возможность создавать растры и работать с их пикселями напрямую. более того: LC использует рисовалку, которая не зависит от host OS (написана на CP), и этой же самой рисовалкой можно рисовать на растрах.

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