OberonCore

коммитнул рисовалку, вместе с расширеной реализацией `DrawComplexPath()`. это вариант без сглаживания, пытаться их объединять будет хуже, чем сделать два отдельных модуля. это универсальная для RGBA буфера, с маленькой капелькой асма. пора пробовать засунуть её в линуксовый хостпорт.

хочу заметить, что чисто технически это будет самая правильная рисовалка, эталон. просто потому что Oberon/F разрабатывался-то как раз на той самой Oberon System, откуда эта рисовалка и взята. так что ответ на вопрос: «нужно ли рисовать последний пиксел в hairline-линиях» будет довольно неожиданный: да, последний нужно; а вот первый — нет. именно таким прикольным образом ведёт себя обероновская линиечертилка. причём вне зависимости от толщины: первый шаг всегда пропускается. котаны, мы всё время делали всё неправильно, потому что в виндочертилке тупо баг!

p.s.: ладно, поправка: для толстых линий, похоже, как раз первый тоже рисуется, если я правильно понимаю механику работы `Brush.Walk()`. а вот для hairline — нет. ой.

я, если что, впилил в рисовалку настроечку, и выставил умолчание в «пропускаем последний». а то больно дофига кода чинить придётся. увы.

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

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

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

то есть, тормозит оно когда весь экран блитается, а по каким-нибудь менюшкам вполне шустро можно бегать. так-то я бы сказал, что по меркам Современного Софта даже и совсем не тормозит, это мы тут просто разбалованы софтом качественным, и пауза в 30-50 миллисекунд весьма заметна. а если сделать битмапы через X-SHM, то будет вполне шустро. надо только пангу выкинуть и заменить на фритайп ещё.

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

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

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

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

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

кстати, подумал: рисование без двойного буфера не нужно. это был хак, приделаный для виндоконтролов, а без него в системе очень красиво: OpenBuffer — «начинаю рисовать», CloseBuffer — «а теперь покажи свой динь-дон». если прямое рисование запретить — можно не чистить каждый раз задний буфер (а это может быть немало, прямо весь экран, например), и не тратить время на блит заднего буфера с альфой. я так, наверное, и сделаю, ибо нечего тут. это и в принципе для переносимости будет лучше, потому что цепочка «открыл экран, порисовал, закрыл экран» описывает практически любые ситуации. будем считать, что рисование без открытого буфера — это UB.

охлол. а если послать каиру в анус, и кидать пиксбуф через «устаревшую» `gdk_draw_pixbuf()`, то… ВНИЗАПНА! тормоза пропадают. и теперь обероновая рисовалка работает практически с той же скоростью, что и каировская без блитов пиксмапа.

обожаю Новые Прогрессивные Технологии! жаль, что Молодым Талантливым Программистам не сообщили одну очень важную тайну: прогресс и улучшение — это когда всё работает быстрее, а не медленней.

впрочем, чего я хочу от поколения электрона…

p.s.: по этому поводу постараюсь скоро перейти на LC с обероновским бэкэндом. догфидинг, все дела.

перешёл на обрендер. посмотрим. да, есть чуть-чуть тормозов, странностей и багов, но в целом — вполне юзабельно.

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

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

как известно, картиночки — залог успеха вашего бложега! xor-паттерны на картиночке, увы, пока через gtk — потому что я не нашёл ещё режима xor-blit. и буковки через пангу. но остальной рендер — сильно модифицированая оберон-рисовалка.

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

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

как хорошо, что меня совершенно не волнует ни RTL, ни композиты, ни всё, что находится за первой равниной юникода.

да, добыт именно битмап, без сглаживания. я в курсе, что хинтиг ломает метрики шрифтов при печати на листочки. печатать мне за двадцать лет понадобилось ни разу, а мои глаза мне дороги как память. только хардкор, только m$ core web fonts (и чуть-чуть паратайпа)!

не могу не поделиться. comic sans, говорите? да ладно, мы из любого шрифта можем сделать комик санс!

"Душераздирающее зрелище..."(с) Иа?

А в каком же месте смеяться?
Видеопамяти - вагон, дисплеи - 4K едва ль ни метр в диагонали, чуть менее чем у каждого... и вот так "назад на пальму в светлое будущее" - шрифты битмапом. /-8Ж

шрифты ttf-ом. но без сглаживания. потому что — как я уже писал — мне мои глаза очень дороги. я очень плохо вижу, и когда графика нерезкая, с соплями — я автоматически начинаю щуриться и пытаться навести резкость. от этого и глаза болят, и голова. поэтому я добываю из freetype strictly black and white, а не greyscale.

Лекарство хуже болезни какое-то получается.

ну дык кому не понравится — возьмёт исходник и починит. надо поменять один флаг, да сделать декодер grayscale вместо b/w (что проще, потому что там байт на пиксель). лично мне оно не надо — я себе этого делать не буду. когда закоммичу новые HostPorts и HostFonts — желающие смогут допилить. там обычный fontconfig да freetype, ничего сложного.

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

доделал (кое-как) подчёркивание и перечёркивание. в целом всё работает (только блиты растров сломались, потому что забыл сделать flush на задний буфер; потом).

кернинг в OpenType, конечно, пошёл по половому органу — потому что там не обычные таблицы, а хитрожопость, и надо тащить обратно пангу/харфбаз; но мне оно нафиг не надо, и панга не нужна, и харфбаз не нужен. в обычных старых добрых вердане со товарищи кернинг есть, и этого хватает.

также (панга/харфбаз!) пошёл в пень механизм подстановки отсутствующих глифов из других шрифтов. опять таки: это меня более чем устраивает, just as planned. все шрифты, которые у freetype не получается загрузить, тупо меняются на прибитую гвоздями вердану. иба ваистену.

ещё раз замечу, что меня это всё полностью устраивает: все мои уй-тулкиты давно работают именно так. быстро, дёшево, сердито, покрывает 99% (моих) потребностей. иероглифы, всякое RTL и композиты рендерить не будет — но это никогда в планы и не входило. вообще, всё ненужное и сложное заменяется на стандартный replacement char; композиты тоже.

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

p.s.: после избавления от панги и лишних flush скорость отрисовки вернулась к нормальному «мгновенно, т.е. без ощутимых пауз». остался один flush для `MarkRect()`, но теперь можно будет и от него избавиться: мне, в принципе, больше не нужно пользоваться механизмами гтк для двойной буферизации, у меня всегда этот самый задний буфер присутствует.