Разве мы уже не исследовали в свое время скорость случайной и последовательной записи в видеопамять. Чем обосновывается первое утверждение?art_zh wrote:Растровые - значит медленные.
Векторные (без растеризации) быстрее и компактнее.
Какие на данный момент есть наиболее приоритетные задачи?
Более детально посмотрел на fontslib, выводы:
1) получается что либо нужно впихивать все функции в box_lib, или давать ссылку на функцию font_draw_on_string из внешней программы
2) шрифты ограничены размером 8*16 :
1) получается что либо нужно впихивать все функции в box_lib, или давать ссылку на функцию font_draw_on_string из внешней программы
2) шрифты ограничены размером 8*16 :
Code: Select all
push dword (8 shl 16 +16) ; поиск нужного шрифта в наборе шрифтов (пока доступен только 8х16)
call [get_font]
Растеризованный битмап 8х16 = это (минимум!) 128 пикселей в любом символе.Mario wrote:Разве мы уже не исследовали в свое время скорость случайной и последовательной записи в видеопамять. Чем обосновывается первое утверждение?art_zh wrote:Растровые - значит медленные.
Векторные (без растеризации) быстрее и компактнее.
Даже в пробеле.
Векторные цепочки пикселей будут выводиться гораздо быстрее. Просто потому что реальных пикселей в тексте - почти в 10 раз меньше.
Если тупо выводить, то да, но текущие растровые системные шрифты выводятся попиксельно, ничего не мешает выводить попиксельно и новые.art_zh wrote:Растеризованный битмап 8х16 = это (минимум!) 128 пикселей в любом символе.
Даже в пробеле.
Векторные цепочки пикселей будут выводиться гораздо быстрее. Просто потому что реальных пикселей в тексте - почти в 10 раз меньше.
Векторные шрифты без растрирования налагают дополнительную множественную математическую обработку, а с растрированием получается то же самое что и растровые. Никто ведь не собирается по тупому выводить. Пробел при прочих условиях вообще не нужно рисовать, разве что идет вывод шрифта с фоном.
У меня есть компромиссное предложение:
1. Чтобы не переписывать кучу программ пусть вывод остается функцией 4 (Ring3 овцы целы?), но при выборе третьего шрифта ядро переадресовывает обработку на заранее установленный обработчик вызывающий код нового шрифта.
2. Допустим с помощью дополнительной функции ядра мы устанавливаем указатель на загруженную библиотеку, которая рисует новые шрифты. Я не уверен насчет всех компонентов Box_Lib, но те которые писал я содержат поля в структурах данные, для оперирования размером шрифта. Так что доработать, чтобы оно было "прозрачным" для старых приложений не накладно.
3. Можно библиотеку сделать в виде подгружаемого драйвера (Ring0 волки сыты?) - важно лишь чтобы не было дублирования растрированных шрифтов, чтобы не кушать зазря память.
1. Чтобы не переписывать кучу программ пусть вывод остается функцией 4 (Ring3 овцы целы?), но при выборе третьего шрифта ядро переадресовывает обработку на заранее установленный обработчик вызывающий код нового шрифта.
2. Допустим с помощью дополнительной функции ядра мы устанавливаем указатель на загруженную библиотеку, которая рисует новые шрифты. Я не уверен насчет всех компонентов Box_Lib, но те которые писал я содержат поля в структурах данные, для оперирования размером шрифта. Так что доработать, чтобы оно было "прозрачным" для старых приложений не накладно.
3. Можно библиотеку сделать в виде подгружаемого драйвера (Ring0 волки сыты?) - важно лишь чтобы не было дублирования растрированных шрифтов, чтобы не кушать зазря память.
А что мешает сделать новый системный вызов ?
Необходимость более масштабного переписывания кода компонентов Box_Lib в моем случае.Serge wrote:А что мешает сделать новый системный вызов ?
Моя идея максимально проста: есть текущая реализация 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.
Почему именно так? Потому что это наикратчайший путь к внедрению этого шрифта во все программы. Нет, разумеется, можно начать переписывать все программы с использованием fontslib, но зачем тратить очень много времени на совершенно бесполезный мартышкин труд? Ведь одно дело - изменить координаты вывода, а совсем другое - разбирать каждую программу и внедрять в нее fontslib.
Mario
Переписывать всё равно придётся. Потому что опять предлагается костыль.
Переписывать всё равно придётся. Потому что опять предлагается костыль.
maximYCH, часто программисты используют 4ю функцию и подразумевают, что ширина и высота шрифта строго определенные. После изменения размеров системных шрифтов 90% (ну или несколько меньше) программ с GUI придется все равно переписывать. Заодно желательно закладывать в них возможность работы на сверхвысоких разрешениях (т.е. на высоких dpi) - чтобы иконки и кнопки не были очень маленькими.
Иконки помнишь? Буфер обмена помнишь?... Прошло полгода: Шрифты помнишь?Serge wrote:Mario
Переписывать всё равно придётся. Потому что опять предлагается костыль.
иSorcerer wrote:maximYCH, часто программисты используют 4ю функцию и подразумевают, что ширина и высота шрифта строго определенные. После изменения размеров системных шрифтов 90% (ну или несколько меньше) программ с GUI придется все равно переписывать.
По-моему это про одно и то жеmaximYCH wrote: я согласен исправить координаты вывода в существующих программах
Одними координатами вывода не обойтись. Нужно менять абсолютно всю GUI-часть. Алгоритмы расчета высоты panel, меню-баров в animage и tinypad, расположение кнопок. Это не на день и не на два работы.
А кто-то спорит? Я ведь ничего не упоминал о сроках.
Who is online
Users browsing this forum: No registered users and 2 guests