Масштабируемые шрифты

Kernel-side graphics support
  • Имхо хорошо иметь 1 конфигурационный файл, в котором это будет прописано. Вообще тема дискусий. Но пока каждая программа сама будет выбирать тип шрифта который она захочет выводить.
  • <Lrz>
    Супер!... это сильно поменяет мой проект, и это замечательно!... :D :D :D
    *****:
    ;дух машины, мой бубен сильнее твоей тупости

    *****:
  • > как ты знаешь на больших объемах это тормоза
    Знаю. Потому пусть такой вывод остается опциональным, о чем я и говорил. Или вывод прозрачных символов можно сделать только на bitmap.

    > тебе потребуется 200х128=25600
    Количество вызовов функций для формирования всех глифов будет составлять 8*16*256=32768, много кто бы спорил. Но это единовременная операция, в дальнейшем будут использоваться эти кешированные глифы, о чем я и говорил. Ты ведь, перед выводом текста, будешь формировать с кешированием необходимые изображения символов в соответствии со шрифтом и цветом, а в дальнейшем будешь использовать это изображение для вывода? Или ты будешь формировать такое изображение налету?

    > Далее при формировании градиента возможны тормоза при выводе, или увеличению использования ОЗУ
    То же что и выше. Ну и вопрос тот же. Если глифы полностью заранее подготовленны, то всё равно как это сделано, вывод в любом случае займет одно и то же время.

    p.s. Вызов callback для цвета точки глифа каждый раз при выводе, это не самая лучшая моя идея, такой вариант врядли стоит предусматривать, а вот для формирования глифа, вроде альтернативы константному цвету, почему бы и нет, тогда и градиент с тебя снимается. Как я и говорил ранее.

    ..bw
  • Конечно может Serge или кто -то еще и прикрутит шрифты от иксов, но я думаю без аппаратной акселерации это будет медленно.
    Не будет. Сейчас все всё рисуют программно. В ХАА ещё есть аппаратный вывод линий и глифов, в новом ЕХА оставили только блитер.
    Прицип такой же. Программа рисует всё в битмап а потом акселератор выводит битмап на экран. Это позволяет и шрифты сглаживать и градиент делать. Кстати в pixlib уже есть почти всё для этого необходимое. И прозрачность и альфа.

    P.S. В никсах все работают с freetype. Как насчёт неё ?
  • > В никсах все работают с freetype. Как насчёт неё ?
    Пойдет. Когда займешься :-)?

    ..bw
    Last edited by bw on Sat Nov 01, 2008 8:59 am, edited 1 time in total.
  • bw
    Объясню работу 65 функции для вывода изображения. В памяти при загрузке либы будет размещены глифы изображения в виде массива в формате raw. При выводе изображения т.е. при вызове 65 функции ты указываешь цвет слоев. т.е. на примере простого:
    Загрузил ты монохромный шрифт каждая точка кодируется битом т.е. 8х16х256=32768 бит или 4096 байт. Так вот при выводе можно указывать цвет в формате RGB для каждого слоя т.е. фон и цвет символа могут быть любыми в формате RGB. В описании функции 65 можно работать минимально с 8 битным изображением. Вообще в документации оч хорошо сказано

    Code: Select all

    Функция 65 - вывести изображение с палитрой в окно.
    Параметры: 
    eax = 65 - номер функции 
    ebx = указатель на изображение 
    ecx = [размер по оси x]*65536 + [размер по оси y] 
    edx = [координата по оси x]*65536 + [координата по оси y] 
    esi = число бит на пиксель, должно быть 8, 24 или 32 
    edi = указатель на палитру (256 цветов 0x00RRGGBB); игнорируется при esi = 24 и 32 
    ebp = смещение данных каждой следующей строки изображения относительно предыдущей 
    Замечания: 
    Координаты изображения - это координаты верхнего левого угла изображения относительно окна. 
    Размер изображения в байтах есть xsize*ysize. 
    Каждый байт изображения рассматривается как индекс в палитре. 
    Если изображение использует не все 256 цветов, а меньше, размер палитры может быть меньше 256. 
    Т.е. сам пользователь может выбрать цвет глифа и фона по своему усмотрению.

    На счет формирования изображения. Изображение будет формироваться в памяти, т.е. выделится буфер, и в него будут копироваться глифы, и все операции по наложению и т.д. будут происходить только с этим буфером. Затем, готовое изображение будет выведено на канву.

    Serge
    P.S. В никсах все работают с freetype. Как насчёт неё ?
    Итак рассмотрим модульный принцип построения работы со шрифтами.
    В любом случае freetype шрифты нужно будет преобразовывать в raw массив для вывода изображения (если будет испльзована 65 функция для вывода) Думаю то же справедливо и для pixlib. Однако, нужно описание API что бы говорить более конкретно.
    Т.е. общее у разных шрифтов, это формирование raw массива для вывода. Если использовать один и тот же формат буфера для вывода изображения, то можно использовать в системе различные типы шрифтов.
    У меня есть примеры на С для работы с freetype, но пока нету времени что бы их начать разбирать...
  • Непонятно, к чему этот ликбез по 65'ой функции. Я знаю о её существовании и о том какие параметры она принимает. Возможно ты так, по своему, хотел сказать, что глифы у тебя будут 8'ми битные, а при выводе будет использоваться 65'ая с палитрой из двух индексов. Из того что ты сказал выше (про 65'ую) я никак не могу связать с "Т.е. сам пользователь может выбрать цвет глифа и фона по своему усмотрению.".

    p.s. Ладно, это всё демагогия. Уверен, что и без моих советов справишься.

    ..bw
  • bw
    Если ты знаешь о существовании 65 функции, и как она работает, то при использовании 8 битных глифов и палитры из 2-х цветов в формате RGB можно добиться вывода глифа(ов) в любой цветопередаче. Если говорить о 24 и 32 битных составляющих на пиксель, то в этих режимах можно выводить и градиент и вообще использовать любую маску.
    В большинстве случаев требуется использование только вывод глифов с указанием цвета фона и самого символа. Так вот, в 8 битных глифах, достаточно изменить палитру для формирования нужного цвета глифа, а эти параметры можно передавать при вызове функции, которая выводит глиф(ы) или формирует изображение в массиве озу.
  • Во вложении пример, скрин которого был выше. Можно потестировать скорость вывода глифов. В примере сделано не оптимально, в дальнейшем скорость будет увеличена, как в принципе будет и библиотека, над которой я тружусь. Для тестирования нужна библиотека box_lib.obj в /sys/lib, версия ядра начиная с SVN 912.
    Attachments
    font_ex.7z (2.28 KiB)
    Пример, который можно проверить на скорость вывода. Нужна box_lib.obj в /sys/lib
    Downloaded 254 times
  • Выглядит отлично :)
    Из хаоса в космос
  • Предлагаю обсудить API библиотеки масштабируемых шрифтов:

    Пока я сделал следующее:
    функция initialization_font инициализация, функция типа viod.
    Получает список файлов в папке /sys/FONTS.
    Если функция выполнилась не успешно возвращает в eax =-1

    функция get_font - получить т.е. загрузить нужный шрифт
    входные параметры: в стек запихиваем dword ширина shl 16 + высота (ширина*65536 + высота)
    По этому параметру происходит поиск подходящего шрифта и если нашли - загружаем его. если ничего не нашли возвращаем в eax=-1

    функция free_folder_info осободить память занимаемую при вызове initialization_font
    эта функция осовбождает всю память где храниться информация о файлах из папки /sys/FONTS.

    функция free_font - тип void, освобождает память занимаемую загруженым шрифтом

    Предложения по другим функциям в формате который я описал выше.
    Last edited by <Lrz> on Fri Nov 07, 2008 11:09 am, edited 1 time in total.
  • Я считаю логичнее загружать шрифт по его имени (либо по имени файла).
    А после загрузки, перед выводом, указывать какой кегль (размер в пикселях) должен использоваться. Если не удается установить размер (а на первых парах так и будет, как я пологаю), то используется ближайший возможный, либо единственный возможный.

    Code: Select all

    f = font_load(name)
    font_set_size(f, size)
    font_get_size(f)
    font_close(f)
    
    В таком духе. А еще можно слизать один из множества существующих API.

    ..bw
  • <Lrz> wrote: функция free_fulder_info осободить память занимаемую при вызове initialization_font
    эта функция осовбождает всю память где храниться информация о файлах из папки /sys/FONTS.
    А что такое fulder? Может folder? Или я ламер и что-то не так понял? :)
  • bw
    Сейчас заголовок шрифта имеет вид

    name_head db 'fnt1' - это тип шрифта
    font_size dd 8 shl 16 +16 ;font_width shl +font_height
    font_start dd font - смещение до реальных данных т.е. до raw картинки с цветопередачей 1 bpp.
    font_name db 'font raw format 8x16',0 - имя шрифта в формате ASCIIZ
    align 16
    font:
    file 'font_8x16.fon' - raw картинка с цветопередачей 1 bpp.


    Т.к. сейчас шрифты не имеют возможности масштабироваться, то можем иметь картину с одинаковым именем. Лучше если будет возможность указывать как в формате размер, имя, или размер + имя. для получения нужного шрифта. Сейчас при инициализации шрифта идет проверка на тип файла т.е. проверяется наличие у файла расширения типа .fnt, далее проверяется его заголовок на тип 'fnt1' если он совпадает с этими требованиями, то функция get_font уже может работать с этим файлом.
    По дефолту получить тип шрифта то же можно, но где-то должна храниться информация о настройках - есть предложения?
    А после загрузки, перед выводом, указывать какой кегль (размер в пикселях) должен использоваться. Если не удается установить размер (а на первых парах так и будет, как я пологаю), то используется ближайший возможный, либо единственный возможный.
    Можно, если функция get_font не нашла указываемый шрифт, будет загружен ближайший и вернется в программу информация о кегле.

    P/S Можно ссылку на описание API как это сделано в других системах ?

    Heavyiron
    поправил.
  • Who is online

    Users browsing this forum: No registered users and 3 guests