Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пн ноя 20, 2017 8:29 pm

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




Начать новую тему  Ответить на тему  [ 134 сообщения ]  На страницу Пред. 15 6 7 8 9
Автор Сообщение
СообщениеДобавлено: Чт сен 15, 2011 10:04 pm 
art_zh писал(а):
Растровые - значит медленные.
Векторные (без растеризации) быстрее и компактнее.

Разве мы уже не исследовали в свое время скорость случайной и последовательной записи в видеопамять. Чем обосновывается первое утверждение?


Вернуться к началу
   
СообщениеДобавлено: Чт сен 15, 2011 10:11 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пн окт 27, 2008 10:10 pm
Сообщения: 750
Более детально посмотрел на fontslib, выводы:
1) получается что либо нужно впихивать все функции в box_lib, или давать ссылку на функцию font_draw_on_string из внешней программы
2) шрифты ограничены размером 8*16 :
Код:
       push dword (8 shl 16 +16)   ; поиск нужного шрифта в наборе шрифтов (пока доступен только 8х16)
       call [get_font]


Вернуться к началу
СообщениеДобавлено: Чт сен 15, 2011 10:28 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Mario писал(а):
art_zh писал(а):
Растровые - значит медленные.
Векторные (без растеризации) быстрее и компактнее.

Разве мы уже не исследовали в свое время скорость случайной и последовательной записи в видеопамять. Чем обосновывается первое утверждение?

Растеризованный битмап 8х16 = это (минимум!) 128 пикселей в любом символе.
Даже в пробеле.
Векторные цепочки пикселей будут выводиться гораздо быстрее. Просто потому что реальных пикселей в тексте - почти в 10 раз меньше.


Вернуться к началу
СообщениеДобавлено: Чт сен 15, 2011 10:40 pm 
art_zh писал(а):
Растеризованный битмап 8х16 = это (минимум!) 128 пикселей в любом символе.
Даже в пробеле.
Векторные цепочки пикселей будут выводиться гораздо быстрее. Просто потому что реальных пикселей в тексте - почти в 10 раз меньше.

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


Вернуться к началу
   
СообщениеДобавлено: Чт сен 15, 2011 11:07 pm 
У меня есть компромиссное предложение:
1. Чтобы не переписывать кучу программ пусть вывод остается функцией 4 (Ring3 овцы целы?), но при выборе третьего шрифта ядро переадресовывает обработку на заранее установленный обработчик вызывающий код нового шрифта.
2. Допустим с помощью дополнительной функции ядра мы устанавливаем указатель на загруженную библиотеку, которая рисует новые шрифты. Я не уверен насчет всех компонентов Box_Lib, но те которые писал я содержат поля в структурах данные, для оперирования размером шрифта. Так что доработать, чтобы оно было "прозрачным" для старых приложений не накладно.
3. Можно библиотеку сделать в виде подгружаемого драйвера (Ring0 волки сыты?) - важно лишь чтобы не было дублирования растрированных шрифтов, чтобы не кушать зазря память.


Вернуться к началу
   
СообщениеДобавлено: Пт сен 16, 2011 12:18 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
А что мешает сделать новый системный вызов ?


Вернуться к началу
СообщениеДобавлено: Пт сен 16, 2011 12:20 am 
Serge писал(а):
А что мешает сделать новый системный вызов ?

Необходимость более масштабного переписывания кода компонентов Box_Lib в моем случае.


Вернуться к началу
   
СообщениеДобавлено: Пт сен 16, 2011 9:09 am 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
Моя идея максимально проста: есть текущая реализация GUI. Выносить его никто особо не торопится из ядра, а это значит, что ещё как достаточно продолжительное время гуй будет в ядре. В гуе есть текущая реализация вывода шрифтов типа char.mt. char2.mt. Есть библиотека fontslib, полезного кода в которой 200 строк, которая способна выводить шрифт типа font01.ksf. Я предлагаю изменить dtext в gui/font.inc так, чтобы dtext выводил шрифт font01.ksf, а не char.mt, учитывая наработки кода, имеющиеся в font01.ksf. Если мне передадут исправленный font.inc, который выводит шрифт ksf формата (а в остальном действует аналогично старому, в первую очередь я говорю о параметрах, принимаемых сисфункцией), то я согласен исправить координаты вывода в существующих программах.

Почему именно так? Потому что это наикратчайший путь к внедрению этого шрифта во все программы. Нет, разумеется, можно начать переписывать все программы с использованием fontslib, но зачем тратить очень много времени на совершенно бесполезный мартышкин труд? Ведь одно дело - изменить координаты вывода, а совсем другое - разбирать каждую программу и внедрять в нее fontslib.


Вернуться к началу
СообщениеДобавлено: Пт сен 16, 2011 10:03 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Mario
Переписывать всё равно придётся. Потому что опять предлагается костыль.


Вернуться к началу
СообщениеДобавлено: Пт сен 16, 2011 1:27 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
maximYCH, часто программисты используют 4ю функцию и подразумевают, что ширина и высота шрифта строго определенные. После изменения размеров системных шрифтов 90% (ну или несколько меньше) программ с GUI придется все равно переписывать. Заодно желательно закладывать в них возможность работы на сверхвысоких разрешениях (т.е. на высоких dpi) - чтобы иконки и кнопки не были очень маленькими.


Вернуться к началу
СообщениеДобавлено: Пт сен 16, 2011 1:49 pm 
Serge писал(а):
Mario
Переписывать всё равно придётся. Потому что опять предлагается костыль.

Иконки помнишь? Буфер обмена помнишь?... Прошло полгода: Шрифты помнишь? :cry:


Вернуться к началу
   
СообщениеДобавлено: Пт сен 16, 2011 1:52 pm 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
Sorcerer писал(а):
maximYCH, часто программисты используют 4ю функцию и подразумевают, что ширина и высота шрифта строго определенные. После изменения размеров системных шрифтов 90% (ну или несколько меньше) программ с GUI придется все равно переписывать.

и
maximYCH писал(а):
я согласен исправить координаты вывода в существующих программах

По-моему это про одно и то же ;)


Вернуться к началу
СообщениеДобавлено: Пт сен 16, 2011 1:55 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Одними координатами вывода не обойтись. Нужно менять абсолютно всю GUI-часть. Алгоритмы расчета высоты panel, меню-баров в animage и tinypad, расположение кнопок. Это не на день и не на два работы.


Вернуться к началу
СообщениеДобавлено: Пт сен 16, 2011 1:59 pm 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
А кто-то спорит? Я ведь ничего не упоминал о сроках.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 134 сообщения ]  На страницу Пред. 15 6 7 8 9

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


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

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


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

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