Немасштабируемые векторные шрифты

Kernel-side graphics support
  • А у тебя ещё осталась программа для измерения скорости?
  • базовый код здесь - в окне тинипада viewtopic.php?f=36&t=1979&start=27

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

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

    Я действительно не собираюсь выводить миллионы символов в секунду, но трёхкратная разница в скорости демонстрирует, насколько нерационально вызывать парад на каждую точку. Итак, я планирую выводить строку как изображение через промежуточный буфер, что скажите?
    Attachments
    third bypasses putpixel.PNG
    third bypasses putpixel.PNG (3.62 KiB)
    Viewed 9000 times
    Last edited by Pathoswithin on Sat Jul 11, 2015 11:50 pm, edited 1 time in total.
  • Pathoswithin wrote:К сожалению, NSV шрифты так и не захотели работать на основном ядре, но похоже, что прирост скорости связан исключительно с отказом от putpixel, ибо растровые шрифты без него работают ещё быстрее
    Ежу понятно что без putpixel быстрее.
    Насчет "исключительно" я бы не зарекался.Тест от 28 марта 2012 года замерял время рисования с попиксельной проверкой.
    50% ускорения - только для самого маленького шрифта0; на 1-м шрифте ожидалось трехкратное ускорение, а на более крупных шрифтах векторный фифект должен был быть еще заметнее.
    "Угловая" проверка была добавлена позже, в августе.
    Лучше продумай как без проверки экранной карты обеспечить надежное разделение GUI-ресурсов.

    Что значит "не захотели работать"? Ты смотрел как они в А-ветку вставлены?
  • art_zh wrote:"Угловая" проверка была добавлена позже, в августе.
    Хорошо, вот.
    Attachments
    long string.PNG
    long string.PNG (5.52 KiB)
    Viewed 8973 times
    overlapped.PNG
    overlapped.PNG (6.28 KiB)
    Viewed 8973 times
  • art_zh wrote:Что значит "не захотели работать"? Ты смотрел как они в А-ветку вставлены?
    Некоторые переменные уже удалены. Чтобы собрать, пришлось заменить их на аналогичные из структуры _display. Но увы, программа падает.
    art_zh wrote:Лучше продумай как без проверки экранной карты обеспечить надежное разделение GUI-ресурсов.
    Наверно нужно делать стек окон, и слать события перерисовки в порядке глубины расположения. Будет рисоваться лишнее, но не нужно ничего проверять. Если окон не слишком много — будет быстрее.
    art_zh wrote:50% ускорения - только для самого маленького шрифта0; на 1-м шрифте ожидалось трехкратное ускорение, а на более крупных шрифтах векторный фифект должен был быть еще заметнее.
    Я вообще не понял, из-за чего у векторных шрифтов может быть ускорение. Посмотри на реализацию — порвёт любой векторный шрифт при любом разрешении.
    Attachments
    font.inc (3.26 KiB)
    Downloaded 382 times
  • 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 прогонов):

    Code: Select all

    .char:
      mov al, [font1+ebx]
    .raw:
      bsf dx, ax
      jz  @f
      mov [edi+edx*4], ebp
      btr ax, dx
      jmp .raw
    @@:
      inc ebx
      add edi, [esp+8]
      dec ecx
      jnz .char
    Векторный шрифт в принципе не может работать быстрее. Ну а размер — да, это смысл векторной графики.
  • Да, теперь вижу: цикл будет крутиться, пока в строчке есть черные пиксели.
    Так действительно лучше.
    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"?
    Сделаем мир лучше!
  • Who is online

    Users browsing this forum: No registered users and 2 guests