Board.KolibriOS.org

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

Более детально посмотрел на fontslib, выводы:
1) получается что либо нужно впихивать все функции в box_lib, или давать ссылку на функцию font_draw_on_string из внешней программы
2) шрифты ограничены размером 8*16 :

       push dword (8 shl 16 +16)   ; поиск нужного шрифта в наборе шрифтов (пока доступен только 8х16)
       call [get_font]

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

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

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

А что мешает сделать новый системный вызов ?

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

Моя идея максимально проста: есть текущая реализация 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.

Mario
Переписывать всё равно придётся. Потому что опять предлагается костыль.

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

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

и

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

Одними координатами вывода не обойтись. Нужно менять абсолютно всю GUI-часть. Алгоритмы расчета высоты panel, меню-баров в animage и tinypad, расположение кнопок. Это не на день и не на два работы.

А кто-то спорит? Я ведь ничего не упоминал о сроках.