OberonCore

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

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

так, для информации: сопливый растеризатор в обероновском коде тоже есть, конечно. выглядит он традиционно отвратительно, никаму ни рикамендую такую игру. если уж делать соплерендер, то по заветам Макса Шеманарёва.

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

сам задний буфер — честное RGBA (альфа всегда ставится в 255), так что его, например, можно использовать как текстуру для OpenGL. да и вообще — блитать куда угодно, любым удобным способом. можно даже VNC-сервер организовать, гыг.

созданые руками растры тоже RGBA, и вот они как раз блитаются в задний буфер с учётом альфы.

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

сама рисовалка живёт в модуле Drawpathes, и просто тупо рисует в RGBA-буфер (с прямоугольным отсечением, и простеньким трекингом грязной области). на вход она поучает UC и юнит, что позволит в будущем заменить её на AA-рисовалку, например, не трогая реализацию хост-портов вообще.

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

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

ах, да. виндовый MDI-вариант тоже доживает последние дни: я категорически считаю, что он не нужен.

p.s.: скриншот не прилагаю, потому что визуально изменилось ровно ничего.

всё, линукс-хост с рендером через gdk официально нюкнут. прямо из репозитория. заодно загеноцидил хосты под *бсд: у меня оных бсд нет, добровольцев допиливать это до ума нет — а потому и нет смысла эти хосты в репозитории держать. если вдруг понадобится — всегда можно добыть основу из коммита до нюка и пилить.

да, я, вроде бы, про сравнительное быстродействие не написал. чиста канкретна профайлить мне лень: баловство это в данном случае; важно то, как система ощущается. у меня, если что, по нынешним меркам стандарты очень высокие, и «не тормозит» — это когда система реагирует (визуально в том числе) на мои действия так, чтобы у меня было ощущение «сделало раньше, чем я кнопку успел нажать как следует».

так вот: моим стандартам быстродействия удовлетворяет. все тормоза на кучу миллисекунд, которые были от гибрида «оберон-рендер + ошмётки каиры/панги» полностью исчезли, система как минимум не медленней, чем была. субъективно даже чуть-чуть быстрее, но это скорее всего иллюзия. я сильно подозреваю, что если сделать блит напрямую в иксы через X-SHM, то и ещё быстрее будет. так что соблюдая «оберон-чистоту», мы в эффективности для конечного пользователя ничего не потеряли.

должен сразу признаться, что в рендере есть немного ассемблера. ассемблер занимается заполнением картинки сплошным цветом, пытаясь при этом долбить аж по восемь пикселей за раз через SSE. в принципе, даже при простом REP STOSD тормозов не будет, но у меня уже была под рукой SSE-заполнялка, так почему бы её и да. в принципе это всё лишнее, конечно, и premature optimisation; но ничего не могу с собой поделать: люблю такое.

есть недостаток: требуется видеорежим true color (24 бита на пиксель). gdk-бэкэнд (чисто теоретически) мог без изменений работать и в других режимах, а вот нынешний не сможет. в 15/16 бит на пиксель, впрочем, можно просто сделать спецблитер, а вот с режимами 8 бит/пиксель (или, упаси демоны, 4) будут большие проблемы. я считаю, что это нормальный tradeoff: всё равно во всякие embedded, где такое можно встретить, ящик пока что не влезет, а в остальных местах true color — давно стандарт де-факто.

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

кстати, надо добавить возможность рисовать в растр текст обычными шрифтами.

также забавная фича оберонорисовалки: если ей подпихнуть для работы растр с нулевой альфой, и на нём порисовать, то все изменённые пикселы будут иметь альфу 255, а остальные всё ещё 0. это, натурально, можно потом блитнуть.

кстати. в A2 есть builtins для 64-битной арифметики. очень мне не нравится, что она сопроцессор использует. с одной стороны — таки проверка на переполнения. с другой — а она реально нужна? в интах-то её нет. и вообще, меня пугает трап про кривой результат флоатинг поинта, когда я очевидно работаю с интами.

забавно, что у омиков были процидурки, а потом их заменили на FPU. могли бы исходники процидурок-то и оставить, жадины.

слушайте, а не знаете, в каком релизе заменили? может, оттуда выколупать можно будет, чтобы Аутентично совсем.

накодироваел LONGINT-ы без FPU. dev-бинари пока что старые, компилер же генерит вызовы процедур из Builtins486. кое-какие инлайном, кое-какие так. проверяю в экспериментальном режиме.

А как по скорости?

сложно сказать, бенчмарков же нет нифига. ;-) если попробовать чистую логику, то оно примерно так: сравнения, NEG, ABS, MIN и MAX, ADD, SUB — инлайнятся, поэтому за счёт избавления от прохода через FPU должны быть чуть-чуть быстрее (хотя код, конечно, избыточный, и немного pipeline stalls есть). умножение, деление и остаток — через вызовы процедур с довольно сложной логикой (особенно деления), так что скорее всего чуть медленней. заодно добавил (но не тестировал и толком не допилил) код для битовых сдвигов.

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

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

также компилятор пока не делает оптимизаций при делении/умножении на константы-степени двойки (это надо добавить, вполне можно впихнуть в CPH), тогда стандартное применение для получения байтиков и сдвигов будет даже шустрее FPU, думаю.

в целом, считаю, что тяжёлая математика с кучей умножений и делений (особенно делений) будет немного медленней. остальное должно быть как минимум не хуже.

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

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

А не хотите попробовать сделать diff читаемым, прописав текстовый преобразователь в этом репозитории?

добавил оптимизации деления/умножения для LONGINT-ов. код всё ещё не самый лучший, но хотя бы вставляет сдвиги и маски вместо вызова деления/умножения. заодно докинул забытые ASH/LSH/ROT.

кстати, CP2 довольно забавно хранит LONGINT-литералы: младшие 24 бита в intval, а остальное (с обнулёнными младшими битами) в realval. прикольная схема чтобы не потерять точность (в IEEE double только 52 бита мантиссы), и чтобы самому компилятору не нужна была поддержка LONGINT.

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

p.s.: а если локально, то я фиг знает, синкаются ли атрибуты, но всё равно не хочу. меня вполне устраивает моя дифалка в самом LC (ну, не то чтобы совсем, но я её потом допилю). просто И.Д. просил давать ссылки на коммиты, когда что-то интересное — я исполняю.

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

Ясно. Я не всматривался в сайт и просто подумал, что это что-то ваше.

это Просто Гит Хостинг, от чешского университета. приятен тем, что во-первых, там нет ничего лишнего (то есть, ничего кроме хранения репозиториев), а во-вторых, на удивление отзывчивой администрацией. за 10+ лет использования у меня пару раз возникали проблемы, администрация отвечала на письма буквально через пол-часа, и проблемы оперативно решала. из относительных недостатков то, что примерно раз в пол-года любит прилечь на день-два-три. видимо, техобслуживание.

если что — то категорически рекомендую. не едят мозг ложками, ничего не требуют, Просто Работают, как говорится.

p.s.: а вообще, конечно, Fossil наше всё. я как-нибудь репозиторий конвертирую — как только с libfossil разберусь.

кстати, если кто будет смотреть в CPH: я оставил старый омиковский код для замены на вызовы вполне целенаправленно, и испортил новый проверками тоже целенаправленно. да, вышло немного грязновато, ну да чего уж.

по уму, конечно, в большинстве случаев (все кроме деления и умножения) надо просто научить кодоген вставлять нужный код по месту (там сейчас инлайновые [code], не так уж плохо, но лишние push/pop). потом, может, и научу, а для PoC было проще сделать так. с другой стороны — особого смысла мучить кодоген нет, потому что всё равно никто не ожидает от лонгинтов особого быстродействия. из плюсов разве что можно будет избавиться от модуля Builtins (сейчас его приходится явно собирать первым), и просто добавлять процедуры деления и умножения, если они использовались, сразу в модуль (сейчас компилятор так делает с кодом stack walking).

ещё учтите, что бессмысленная операция `expr MOD 1` безусловно заменяется на нолик, игнорируя любые сайд-эффекты в expr: это потому что мне лень было писать анализатор наличия сайд-эффектов. полагаться на такое поведение компилятора не стоит: в будущем я, возможно, это починю.

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

вот так вот. этот ужас сишники считают «natural, easy to write, compact, and obvious to fluent readers». найдено вот тут.

и вот этим людям мы пытаемся рассказать про прелести типизации, и про то, что программы пишут чтобы их читали другие люди? abandon hope, как говорится. боженька, жги, там уже некого спасать…

и просто так, чтобы бложег не умирал: рисуем Кросивое. это будет потом диалог выбора цвета. почему именно в таком виде? а нипочему, просто Кросивое. один фиг все такие диалоги служат для грубого выбора по картинке и потом файн-тюнинга руками; мне вот нравится выбор из сот. если что — там сбоку будет ещё шкала с яркостью от 0 до 1 (это у нас HSV, если кто не узнал). в Ports, кстати, некоторое время назад были добавлены конверсии для HSV/HSL/CMY[K].