Board.KolibriOS.org

Mario
Я по-моему, с самого начала говорил, что новые шрифты - для всех.
Экспериментирую на А-платформе, чтоб не мусорить в транке.
А черновики заливаю на SVN - чтоб застолбить формальный приоритет, иначе акулы проглотят вместе с ластами.

Лицензия - открытая (Public Domain с копирайтом на команду KolibriOS, 2011),
черновой формат шрифтов и описание структуры данных даны на 1-й странице этой темы, даты публикации - 26 и 28 ноября 2011, парсер и первый работающий шрифт залиты на SVN в марте 2012.

А у тебя ещё осталась программа для измерения скорости?

базовый код здесь - в окне тинипада viewtopic.php?f=36&t=1979&start=27

4-й функцией рисую строчку текста, а с помощью rdtsc засекаю время (в тактах), потраченное на вывод.

потом вывожу это время 47-й функцией слева от каждой строчки.

К сожалению, NSV шрифты так и не захотели работать на основном ядре, но похоже, что прирост скорости связан исключительно с отказом от putpixel, ибо растровые шрифты без него работают ещё быстрее.

Я действительно не собираюсь выводить миллионы символов в секунду, но трёхкратная разница в скорости демонстрирует, насколько нерационально вызывать парад на каждую точку. Итак, я планирую выводить строку как изображение через промежуточный буфер, что скажите?

Pathoswithin wrote:К сожалению, NSV шрифты так и не захотели работать на основном ядре, но похоже, что прирост скорости связан исключительно с отказом от putpixel, ибо растровые шрифты без него работают ещё быстрее

Ежу понятно что без putpixel быстрее.
Насчет "исключительно" я бы не зарекался.Тест от 28 марта 2012 года замерял время рисования с попиксельной проверкой.
50% ускорения - только для самого маленького шрифта0; на 1-м шрифте ожидалось трехкратное ускорение, а на более крупных шрифтах векторный фифект должен был быть еще заметнее.
"Угловая" проверка была добавлена позже, в августе.
Лучше продумай как без проверки экранной карты обеспечить надежное разделение GUI-ресурсов.

Что значит "не захотели работать"? Ты смотрел как они в А-ветку вставлены?

art_zh wrote:"Угловая" проверка была добавлена позже, в августе.

Хорошо, вот.

art_zh wrote:Что значит "не захотели работать"? Ты смотрел как они в А-ветку вставлены?

Некоторые переменные уже удалены. Чтобы собрать, пришлось заменить их на аналогичные из структуры _display. Но увы, программа падает.

art_zh wrote:Лучше продумай как без проверки экранной карты обеспечить надежное разделение GUI-ресурсов.

Наверно нужно делать стек окон, и слать события перерисовки в порядке глубины расположения. Будет рисоваться лишнее, но не нужно ничего проверять. Если окон не слишком много — будет быстрее.

art_zh wrote:50% ускорения - только для самого маленького шрифта0; на 1-м шрифте ожидалось трехкратное ускорение, а на более крупных шрифтах векторный фифект должен был быть еще заметнее.

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

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

Гм. На реализацию посмотрел.
От старой версии принципиально отличается только проверкой экранной карты по углам.

Главный недостаток матричных шрифтов - собственно матрица X * Y бит для каждого символа. Отсюда прямо вытекают 2 следствия:
1) Каждый шрифт занимает X * Y * 256 бит. Все эти килобайты висят в ядре и регулярно ломают кэш CPU.
2) отрисовка строчки из N символов требует трехуровневого цикла из X * Y * N прогонов

Как результат, переход к крупным шрифтам потребует квадратичных накладных расходов: например, шрифт 16х20 будет занимать в 7 раз больше места (по сравнению с классическим font0), и рисоваться в 7.5-8 раз медленнее.
Размер векторных шрифтов растет линейно: тот же шрифт 16х20 потребует в примерно в 2 раза больше памяти,
а время отрисовки - будет всего в полтора раза дольше (сублинейный рост)

От старой версии отличается циклом вывода символа, в котором скорость зависит от количества чёрных пикселей (а*Y*N прогонов): Векторный шрифт в принципе не может работать быстрее. Ну а размер — да, это смысл векторной графики.

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

Pathoswithin wrote:Я вообще не понял, из-за чего у векторных шрифтов может быть ускорение.
...
Векторный шрифт в принципе не может работать быстрее.

Если чего-то не понимаешь - лучше не зарекайся насчет "в принципе".

Тебе надо хотя бы один раз просканировать каждую из Y строчек. Даже если в ней нет ни одного черного пикселя.
А векторный шрифт точно знает сколько у него пикселей, и вообще не тратит времени на проверку пустоты.

Нет, я понимаю, что знаки препинания у тебя рисуются быстрее.

art_zh wrote:Лучше продумай как без проверки экранной карты обеспечить надежное разделение GUI-ресурсов.

Всё уже продумано. Что в Windows, что в X11 есть понятие "регион" как некоторая группа пикселей, внутренне представляемая как объединение прямоугольников стандартной ориентации - в смысле, типа (x,y),(x+width,y),(x,y+height),(x+width,y+height). В Windows внутреннее представление даже торчит из API GetRegionData/RGNDATA.

У каждого окна есть видимый регион. Например, при отсутствии скруглённых углов видимый регион у top-level окна - один прямоугольник, у частично перекрытого окна - два прямоугольника. Скруглённые углы реализуются как некоторое количество однопиксельных прямоугольников плюс один большой. При создании/удалении/перемещении окна процедура, пересчитывающая раскладку видимости окон, не пишет результат в оконную карту, а запоминает видимые регионы - у первого окна он совпадает с полным регионом, у второго из полного региона вычитается регион первого окна, у третьего - вычитается объединение первых двух и так далее.

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

Бонус номер 1: размер хранимых данных зависит только от количества окон и "красивостей" отдельных окон, но не от разрешения. Никаких двухметровых таблиц на разрешении 1920*1080, способных убить какой угодно кэш.
Бонус номер 2: никаких ограничений "в системе не может быть больше 256 окон".
Бонус номер 3: помимо системного региона, у окна может быть отдельный регион клиентской области. Никаких случайных заползаний на рамку окна при рисовании, рисование в системной области включить можно, но включать нужно явно. Также может быть отдельный "грязный" регион - если top-level окно закрылось и нужно перерисовать ранее невидимую часть, можно только её и перерисовывать, никаких мерцаний из-за полной перерисовки.
Бонус номер 4: приложение при рисовании может задать свой регион, который будет пересечён с видимым регионом - XCreateRegion/XSetRegion/XIntersectRegion/XUnionRectWithRegion/.../XShrinkRegion/XPolygonRegion в X11, CreateRectRgn/.../CombineRgn/SelectObject в Windows. Отдельным компонентам вроде текстового поля ввода не нужно думать об отсечении самостоятельно, компонент просто устанавливает свою область как регион.

Да, но вопрос наверно был о том, что реально сделать... реально сделать мне одному. Предложенный мной вариант довольно прост, но придётся ждать ответа от окна, и могут быть проблемы. Хотя у вас уже есть функция 12.
Это для максимальной экономии памяти.
Для максимальной производительности, окна могут рисовать не на экран, а в личные буферы-изображения, и далее все действия будут производится с ними, вместо постоянных перерисовок.

Pathoswithin
сабж был про немасштабируемый вариант векторных шрифтов.
убедительно прошу завязывать с оффтопиком.

CleverMouse
обсуждать достоинства чужих GUI тоже можно в другом месте.

Но раз уж зашел такой разговор - прошу зафиксировать, что
1) мне очень нравится изящество, простота и компактность оконных функций Колибри,
2) позволяющая создавать полноценные графические приложения с минимумом временных и инструментальных затрат,
3) и мне меньше всего хотелось бы когда-нибудь увидеть X/Win-подобных монстров в Колибри.

Ну а если мы когда-нибудь исчерпаем все идеи/резервы дальнейшей ассемблерной оптимизации GUI-сервиса - надеюсь что
4) к тому времени удастся запустить аппаратное ускорение графики. Перекинуть оконные функции с ассемблера на VHDL не так уж сложно.

art_zh, я отвечала на твоё же предложение. Или любая идея, реализованная не в Колибри, автоматически плохая и ты ниасилил дальше слов "что в Windows, что в X11"?