Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Сб мар 25, 2017 1:04 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 61 сообщение ]  На страницу Пред. 1 2 3 4 5 След.
Автор Сообщение
СообщениеДобавлено: Пт авг 31, 2012 3:04 pm 
Не в сети
Kernel Developer
Аватара пользователя

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

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

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


Вернуться к началу
СообщениеДобавлено: Чт июл 09, 2015 6:25 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1106
А у тебя ещё осталась программа для измерения скорости?


Вернуться к началу
СообщениеДобавлено: Пт июл 10, 2015 9:07 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
базовый код здесь - в окне тинипада viewtopic.php?f=36&t=1979&start=27

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

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


Вернуться к началу
СообщениеДобавлено: Сб июл 11, 2015 8:03 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

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

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


Вложения:
third bypasses putpixel.PNG
third bypasses putpixel.PNG [ 3.62 КБ | 895 просмотров ]


Последний раз редактировалось Pathoswithin Сб июл 11, 2015 11:50 pm, всего редактировалось 1 раз.
Вернуться к началу
СообщениеДобавлено: Сб июл 11, 2015 9:15 pm 
Не в сети
Kernel Developer
Аватара пользователя

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

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


Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 12:16 am 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1106
art_zh писал(а):
"Угловая" проверка была добавлена позже, в августе.
Хорошо, вот.


Вложения:
long string.PNG
long string.PNG [ 5.52 КБ | 868 просмотров ]
overlapped.PNG
overlapped.PNG [ 6.28 КБ | 868 просмотров ]
Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 12:22 am 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

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


Вложения:
font.inc [3.26 КБ]
22 скачивания
Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 12:19 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Pathoswithin писал(а):
Я вообще не понял, из-за чего у векторных шрифтов может быть ускорение. Посмотри на реализацию — порвёт любой векторный шрифт при любом разрешении.
Гм. На реализацию посмотрел.
От старой версии принципиально отличается только проверкой экранной карты по углам.

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

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


Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 4:55 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

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


Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 9:12 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Да, теперь вижу: цикл будет крутиться, пока в строчке есть черные пиксели.
Так действительно лучше.
Pathoswithin писал(а):
Я вообще не понял, из-за чего у векторных шрифтов может быть ускорение.
...
Векторный шрифт в принципе не может работать быстрее.

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

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


Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 9:52 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1106
Нет, я понимаю, что знаки препинания у тебя рисуются быстрее.


Вернуться к началу
СообщениеДобавлено: Пн июл 13, 2015 7:13 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1591
art_zh писал(а):
Лучше продумай как без проверки экранной карты обеспечить надежное разделение 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. Отдельным компонентам вроде текстового поля ввода не нужно думать об отсечении самостоятельно, компонент просто устанавливает свою область как регион.

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


Вернуться к началу
СообщениеДобавлено: Пн июл 13, 2015 9:33 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

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


Вернуться к началу
СообщениеДобавлено: Пн июл 13, 2015 10:54 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Pathoswithin
сабж был про немасштабируемый вариант векторных шрифтов.
убедительно прошу завязывать с оффтопиком.

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

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

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


Вернуться к началу
СообщениеДобавлено: Вт июл 14, 2015 3:13 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1591
art_zh, я отвечала на твоё же предложение. Или любая идея, реализованная не в Колибри, автоматически плохая и ты ниасилил дальше слов "что в Windows, что в X11"?

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 61 сообщение ]  На страницу Пред. 1 2 3 4 5 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB