Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Apr 23, 2019 9:49 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 61 posts ]  Go to page Previous 1 2 3 4 5 Next
Author Message
PostPosted: Fri Aug 31, 2012 3:04 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
Mario
Я по-моему, с самого начала говорил, что новые шрифты - для всех.
Экспериментирую на А-платформе, чтоб не мусорить в транке.
А черновики заливаю на SVN - чтоб застолбить формальный приоритет, иначе акулы проглотят вместе с ластами.

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

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
PostPosted: Thu Jul 09, 2015 6:25 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
А у тебя ещё осталась программа для измерения скорости?


Top
   
PostPosted: Fri Jul 10, 2015 9:07 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
базовый код здесь - в окне тинипада viewtopic.php?f=36&t=1979&start=27

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

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


Top
   
PostPosted: Sat Jul 11, 2015 8:03 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
К сожалению, NSV шрифты так и не захотели работать на основном ядре, но похоже, что прирост скорости связан исключительно с отказом от putpixel, ибо растровые шрифты без него работают ещё быстрее.

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


Attachments:
third bypasses putpixel.PNG
third bypasses putpixel.PNG [ 3.62 KiB | Viewed 2075 times ]


Last edited by Pathoswithin on Sat Jul 11, 2015 11:50 pm, edited 1 time in total.
Top
   
PostPosted: Sat Jul 11, 2015 9:15 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
Pathoswithin wrote:
К сожалению, NSV шрифты так и не захотели работать на основном ядре, но похоже, что прирост скорости связан исключительно с отказом от putpixel, ибо растровые шрифты без него работают ещё быстрее
Ежу понятно что без putpixel быстрее.
Насчет "исключительно" я бы не зарекался.Тест от 28 марта 2012 года замерял время рисования с попиксельной проверкой.
50% ускорения - только для самого маленького шрифта0; на 1-м шрифте ожидалось трехкратное ускорение, а на более крупных шрифтах векторный фифект должен был быть еще заметнее.
"Угловая" проверка была добавлена позже, в августе.
Лучше продумай как без проверки экранной карты обеспечить надежное разделение GUI-ресурсов.

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


Top
   
PostPosted: Sun Jul 12, 2015 12:16 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
art_zh wrote:
"Угловая" проверка была добавлена позже, в августе.
Хорошо, вот.


Attachments:
long string.PNG
long string.PNG [ 5.52 KiB | Viewed 2048 times ]
overlapped.PNG
overlapped.PNG [ 6.28 KiB | Viewed 2048 times ]
Top
   
PostPosted: Sun Jul 12, 2015 12:22 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
art_zh wrote:
Что значит "не захотели работать"? Ты смотрел как они в А-ветку вставлены?
Некоторые переменные уже удалены. Чтобы собрать, пришлось заменить их на аналогичные из структуры _display. Но увы, программа падает.
art_zh wrote:
Лучше продумай как без проверки экранной карты обеспечить надежное разделение GUI-ресурсов.
Наверно нужно делать стек окон, и слать события перерисовки в порядке глубины расположения. Будет рисоваться лишнее, но не нужно ничего проверять. Если окон не слишком много — будет быстрее.
art_zh wrote:
50% ускорения - только для самого маленького шрифта0; на 1-м шрифте ожидалось трехкратное ускорение, а на более крупных шрифтах векторный фифект должен был быть еще заметнее.
Я вообще не понял, из-за чего у векторных шрифтов может быть ускорение. Посмотри на реализацию — порвёт любой векторный шрифт при любом разрешении.


Attachments:
font.inc [3.26 KiB]
Downloaded 89 times
Top
   
PostPosted: Sun Jul 12, 2015 12:19 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
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 раза больше памяти,
а время отрисовки - будет всего в полтора раза дольше (сублинейный рост)


Top
   
PostPosted: Sun Jul 12, 2015 4:55 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
От старой версии отличается циклом вывода символа, в котором скорость зависит от количества чёрных пикселей (а*Y*N прогонов):
Code:
.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
Векторный шрифт в принципе не может работать быстрее. Ну а размер — да, это смысл векторной графики.


Top
   
PostPosted: Sun Jul 12, 2015 9:12 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
Да, теперь вижу: цикл будет крутиться, пока в строчке есть черные пиксели.
Так действительно лучше.
Pathoswithin wrote:
Я вообще не понял, из-за чего у векторных шрифтов может быть ускорение.
...
Векторный шрифт в принципе не может работать быстрее.

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

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


Top
   
PostPosted: Sun Jul 12, 2015 9:52 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
Нет, я понимаю, что знаки препинания у тебя рисуются быстрее.


Top
   
PostPosted: Mon Jul 13, 2015 7:13 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
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. Отдельным компонентам вроде текстового поля ввода не нужно думать об отсечении самостоятельно, компонент просто устанавливает свою область как регион.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Mon Jul 13, 2015 9:33 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
Да, но вопрос наверно был о том, что реально сделать... реально сделать мне одному. Предложенный мной вариант довольно прост, но придётся ждать ответа от окна, и могут быть проблемы. Хотя у вас уже есть функция 12.
Это для максимальной экономии памяти.
Для максимальной производительности, окна могут рисовать не на экран, а в личные буферы-изображения, и далее все действия будут производится с ними, вместо постоянных перерисовок.


Top
   
PostPosted: Mon Jul 13, 2015 10:54 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1304
Pathoswithin
сабж был про немасштабируемый вариант векторных шрифтов.
убедительно прошу завязывать с оффтопиком.

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

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

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


Top
   
PostPosted: Tue Jul 14, 2015 3:13 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
art_zh, я отвечала на твоё же предложение. Или любая идея, реализованная не в Колибри, автоматически плохая и ты ниасилил дальше слов "что в Windows, что в X11"?

_________________
Сделаем мир лучше!


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 61 posts ]  Go to page Previous 1 2 3 4 5 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited