OberonCore

Тема сделана по просьбе arisu, чтобы не потерять разные полезные идеи, которые слишком революционны на этапе подготовки беты 2.0, но могут пригодиться как в творческих проектах, так и для решения разного рода проблем в текущей сборке или следующей версии Блэкбокса — инструмента, дающего неограниченные творческие возможности!

спасибо! постараюсь кидать сюда мысли, которые не очень вписываются в планируемый консервативный релиз 2.0, и остальных приглашаю делать то же самое. go wild, как говорится! идея такая, что сюда кидаются «сырые» мысли, и если они оформляются во что-то интересное, то потом для них можно будет заводить отдельную тему с обсуждением.

очередное предложение: добавить в bottleneck вместо DrawRect/DrawOval/DrawPath — универсальные пути с командами, как сделано во многих 2d рисовалках. то есть, что-то типа такого:


остальное реализовать через этот интерфейс.

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

предварительная версия — как обычно — реализована в Lament Configuration, будет чиститься и допиливаться. кстати, вот вам и бинарный формат картинок заодно. ;-)

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

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

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

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

прелесть схемы с complex path в том, что добавление новых команд не требует изменений в API, и не ломает старый код. ну, добавились новые константы — и всё.

кстати, может кто в курсе, что это за формат такой, и чем его на маке делали? просто в исходниках рисовалка называется `DrawMacPicture`, и совершенно отчётливо является реверс-инжинирингом чьего-то формата пикчей (кстати, похоже, не совсем корректным). может кто знает, что это? я просто в маках ваще ничоникак, а любопытно.

p.s.: посмотрел в исходник мак-версии. это, похоже, внутренний формат QuickDraw. и да, рисовалка некорректная. цитата: «QuickDraw coordinates referred to the infinitely thin lines between pixel locations. An actual pixel was drawn in the space to the immediate right and below the coordinate.». потому в картинках регионы отсечения начинаются с `(-1, -1)`. теперь ясно. не то чтобы это имело значение в нашем случае, но забавно.

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

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

кстати. у меня появилась идея, как решить проблему с `f.Input()` раз и навсегда: надо всего лишь добавить в неё параметр `timeout`. если -1, то возвращаться только если было событие с пользовательским вводом. если 0, то просто опросить текущее состояние и выйти. а если больше нуля — ждать пользовательского ввода не дольше указаного количества миллисекунд.

введение таймаута позволит нам проинформировать райдер, чего именно мы от него хотим. и практически в любой оси есть API для ожидания события с таймаутом, которое не выжигает CPU. так и код станет чище (мы будем прямо указывать, чего именно хотим), и `Input()` сможет на основе запроса решать, как и сколько ждать.

в подавляющем большинстве случаев таймаут будет -1, потому что почти во всех циклах проверяется, двигался ли курсор/отжалась ли кнопка.

при положительном таймауте `Input()` не обязательно прождёт всё время: может вернуться и сразу: это на усмотрение реализации. такой таймаут нужен для каких-нибудь анимашек, например.

попробую в LC, посмотрю, что получится. надо только в ссаном готэка найти эту самую процидурку «ждать события с таймаутом» — на иксах-то я бы просто `select()` влепил, а тут…

предварительно впилил. `f.Input()` теперь ожидает событий, если нажата какая-то мышекнопка. также добавил `f.InputWithTimeout()` и `f.QueryInput()`. в bottleneck всё тот же один `Input()`, с таймаутом.

странное поведение при ненажатых кнопках потому, что в основном циклы пишут так: `REPEAT f.Input(…) UNTIL ~isDown`. соответственно, если на входе у нас уже `~isDown`, то не надо ничего ожидать.

эффект наблюдаю: пока мышь не двигается, цпу сидит в 0.0 (чего не удавалось добиться слипами). посмотрю, что сломается. ;-)

в принципе, при таком изменении почти весь старый код будет работать, только немного лучше. редкое исключение — когда `Input()` используют, чтобы спросить текущее положение курсора или нажатые кнопки. это надо заменить на `f.QueryInput()`, иначе будет ой. в оригинальном коде среды такое один раз в Controllers. ещё есть в StdDocuments, StdStdCFrames, StdTabFrames. в некоторых местах (StdLinks) `f.Input()` вызывается до того, как зовут `f.MarkRect()`, это надо починить: оно работает, но некрасиво выглядит.

p.s.: кстати, перестали противно моргать рамки, когда таскаешь несколько выделеных элементов на форме, и выделение, когда копируешь атрибуты текста при зажатой средней мышекнопке.