Какие на данный момент есть наиболее приоритетные задачи?

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

    Code: Select all

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

    Users browsing this forum: No registered users and 4 guests