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

Kernel-side graphics support
  • <Lrz> wrote:Раз ни кто не портировал шрифты, значит пока будет жить со своим форматом шрифтов.
    Я недавно тоже подумывал о своем формате шрифта. Вот приведу пример, пока конечно использовать нельзя, но зато шрифт векторный.
    Attachments
    v_font.7z (6.18 KiB)
    это в будущем может стать векторным шрифтом
    Downloaded 425 times
  • <Lrz>
    Хорошая работа!
    Я вот закончу с компонентами FileBrowser и ProgressBar для BoxLib и прикручу в числе прочего твою библиотеку к zSea и KFM, а если кого-нибудь что-нибудь не устраивает, то у Лео специальная страничка для этого предусмотрена!
  • IgorA wrote:
    <Lrz> wrote:Раз ни кто не портировал шрифты, значит пока будет жить со своим форматом шрифтов.
    Я недавно тоже подумывал о своем формате шрифта. Вот приведу пример, пока конечно использовать нельзя, но зато шрифт векторный.
    Значительных или непреодолимых сложностей в реализации этой идеи нет. Если ты возьмешься за реализацию векторных шрифтов, это будет замечательно. У меня на это нет времени :(. Однако рекомендую посмотреть в сторону распространенных форматов. Т.к. в этом случае не нужно будет самостоятельно изготовлять шрифт в своем формате. Я планирую сделать простую и быструю библиотеку системных шрифтов со своим форматом. Но данная библиотека не отменяет необходимость в реализации устоявшихся форматов шрифтов.
  • Жаль, что в архиве fonts_lib нет исходника программы. Непонятно как в памяти представляется шрифт. Какой формат имеет этот растровый шрифт. Как од декодируется и отрисовываеться.

    В библиотеке libGUI работа со шрифтами происходит посредством менеджера шрифтов.
    Для того, чтобы использовать шрифт в библиотеке, нужно написать декодер шрифта и отрисовщик для менеджера шрифтов. Сейчас в библиотеке есть декодер и отрисовщик только для шрифта CHAR.MT
    Так что в библиотеку несложно добавить поддержку любого шрифта. Был бы только декодер и отрисовщик или хотябы описание формата шрифта, чтобы написать и добавить их. Хотя библиотека libGUI не будет против, если декодирование и отрисовку шрифтов(в буфер оперативной памяти) за неё будет делать какая-то другая библиотека. А libGUI будет только выводить отрисованные символы с учётом их размера и области отсечения.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • andrew_programmer wrote:Жаль, что в архиве fonts_lib нет исходника программы. Непонятно как в памяти представляется шрифт. Какой формат имеет этот растровый шрифт. Как од декодируется и отрисовываеться.

    В библиотеке libGUI работа со шрифтами происходит посредством менеджера шрифтов.
    Для того, чтобы использовать шрифт в библиотеке, нужно написать декодер шрифта и отрисовщик для менеджера шрифтов. Сейчас в библиотеке есть декодер и отрисовщик только для шрифта CHAR.MT
    Так что в библиотеку несложно добавить поддержку любого шрифта. Был бы только декодер и отрисовщик или хотябы описание формата шрифта, чтобы написать и добавить их. Хотя библиотека libGUI не будет против, если декодирование и отрисовку шрифтов(в буфер оперативной памяти) за неё будет делать какая-то другая библиотека. А libGUI будет только выводить отрисованные символы с учётом их размера и области отсечения.
    1) Это версия альфа с самым минимальным номером версии, т.е. особо показывать и нечего.
    2) Сейчас доступен только 1 шрифт 8х16, для добавления других шрифтов нужно перерабатывать алгоритм.
    3) Сейчас существуют несколько функций такие как:
    a) Инициализировать шрифты. Происходит поиск всех доступных шрифтов в папке /sys/FONTS с расширением ksf и версии файла (4 байта в начале 'kf01') выделяется ОЗУ и туда помещается информация о файлах.
    б) Инициализация шрифта нужного размера. В функцию передаем размер шрифта push dword (8 shl 16 +16) ;(размер шрифта 8х16). На выходе 0, если шрифт найден и загружен. Т.е. после выполнения 2-й функции у нас будет загружен шрифт
    в) Отображение ASCIIZ происходит посимвольно т.е. каждый глиф символа отображается 65 функцией.
    г) Освободить все, происходит освобождение ОЗУ, которое заняла библиотека.

    Что планируется сделать:
    Доработка формата шрифта. Общая оптимизация алгоритма. Масштабирование шрифта до нужного размера.
    Разработка следующих функций:
    а) Сформировать из строки ASCIIZ картинку -строчку с глифом выбранного шрифта в буфере на выходе получаем указатель.
    б) То же что и выше, только отображает на канву.
    ...
    остальное будет по мере реализации выше списка.

    Формат файла шрифта:

    Code: Select all

    version_head db 'kf01'  ; типо размер шрифта всегда 4 символа
    font_size1    dd 8 shl 16 +16 ;font_width shl +font_height
    font_start1   dd font_8x16
    ;
    font_size2    dd 16 shl 16 +32 ;font_width shl +font_height
    font_start2   dd font_16_32
    
    dd      -1      ; коенц структуры 
    font_name    db 'Kolibri standart font',0
    align 4
    font_8x16:
    file 'font_8x16.fon'
    align 4
    font_16_32:
    file 'font_16x32.fon'
    
    font_8x16.fon - файл с глифами расположенными последовательно и каждый последующий глиф соответствует коду cp866.
  • а) Сформировать из строки ASCIIZ картинку -строчку с глифом выбранного шрифта в буфере на выходе получаем указатель.
    а) Причём надо добавить возможность формировать картинку с разным количеством бит на пиксель. Это сейчас в Колибри всё рисуется 24-х битным цветом, а для VGA режима система сама конвертирует цвета, делая лишнюю работу которой она не должна заниматься. А когда в Колибри будет поддержка 8 и 16 бит на пиксель, то шрифт нужно будет выводить с той же битностью на пиксель, что и установленный графический режим. А конвертированием цвета с большей битности на меньшую должна заниматься библиотека GUI(например libGUI). При запуске libGUI она определяет битность установленного графического режима и при работе использует буферы и отрисовку той же битности, что и установленный графический режим. Если выводиться изображение или геометрический примитив с другой битностью, то производиться конвертирование в битность установленного видеорежима. Понятно, что такой подход пока не работает в Колибря для VGA режима, потому что нет возможности выводить геометрические примитивы 4-х битным цветом.
    б) Шрифт может выводиться и без фона. В этом случае формировать его как картинку в памяти не очень выгодно, хотя и можно. Для отрисовки шрифта без фона программа или библиотека должна выводить/накладывать шрифт попиксельно.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • andrew_programmer
    А конвертированием цвета с большей битности на меньшую должна заниматься библиотека GUI(например libGUI).
    А может все-таки не надо валить все в одну кучу? Мы только-только отходим от принципа "все в GUI ядра" (причем в некоторых случаях этот отход был психологически болезненным), а ты уже предлагаешь "А давайте все в одну библиотеку запихаем?".
    Я понимаю, что тебе как автору библиотеки это очень удобно - не надо париться с совместимостью с чужими библиотеками, но такой подход не рационален, потому что ущербность других библиотек пока еще не доказана.
    б) Шрифт может выводиться и без фона. В этом случае формировать его как картинку в памяти не очень выгодно, хотя и можно. Для отрисовки шрифта без фона программа или библиотека должна выводить/накладывать шрифт попиксельно.
    Все это очень замечательно, когда все происходит на уроне ядра, где нет переходов с Ring0 на Ring3. При взаимодействии же ядра и приложения каждая точка вызывается int 0x40, что не есть правильно с точки зрения производительности.
    С целью уменьшения накладных расходов, я в свое время несколько оптимизировал функцию 35, в результате получилась функция 36. Которая замечательно так используется в BoxLib элементе MenuBar и позволяет восстанавливать фон, не заставляя приложение перерисовывать элементы своего окна. Так что в случае с прозрачным фоном в шрифте библиотеки fonts_lib.obj это будет работать куда производительней, чем попиксельный вывод. 65 функция всяко быстрее выводит чем функция 1 в цикле, а функция 36 объективней быстрее чем 35 в цикле.

    З.Ы. Андрей не обижайся на мое высказывание, но не стоит торопится, за это время разработка системы совсем на месте не стояла, как это может показаться с первого взгляда.
  • З.Ы. Андрей не обижайся на мое высказывание, но не стоит торопится, за это время разработка системы совсем на месте не стояла, как это может показаться с первого взгляда.
    Разве я когда-то обижался? :)
    Всё, что делается в Колибри - всё к лучшему.
    А может все-таки не надо валить все в одну кучу? Мы только-только отходим от принципа "все в GUI ядра" (причем в некоторых случаях этот отход был психологически болезненным), а ты уже предлагаешь "А давайте все в одну библиотеку запихаем?".
    Нет, всё в одну библиотеку я не предлагаю, да и нельзя всё сваливать в одну библиотеку. Я привёл пример, почему нужно сделать рисование шрифта в памяти с различным количеством бит на пиксель. Если изначально считать, что цвет точки всегда 24-х битный, то при выводе изображения в 8-ми и 16-ти битных разрешениях придётся переконвертировать нарисованный в буфере шрифт в 8 или 16 бит на пиксель. А зачем процессор мучить лишними вычислениями - пусть уж лучше сразу рисует в 8-ми или 16-ти битном цвете.

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

    Со временем, если Колибри научиться работать в разрешениях 8 и 16 бит на пиксель, то возникнет вопрос, "А как отображать в этих режимах 24-х и 32-х битные объекты?". Не сваливать же всю проблему на ядро операционной системы, как то сейчас в VGA режиме. Значит этим должны заниматься библиотеки работающие в user-mode. Единственные библиотеки, которые могут на себя взять эту задачу - это библиотеки GUI. Свою библиотеку я упомянул только в качестве примера и я совсем не считаю, что другие библиотеки хуже моей. Как я уже упоминал, должны быть разные библиотеки GUI, чтобы в зависимомти от задач можно было использовать нужную библиотеку.
    Все это очень замечательно, когда все происходит на уроне ядра, где нет переходов с Ring0 на Ring3. При взаимодействии же ядра и приложения каждая точка вызывается int 0x40, что не есть правильно с точки зрения производительности.
    С целью уменьшения накладных расходов, я в свое время несколько оптимизировал функцию 35, в результате получилась функция 36. Которая замечательно так используется в BoxLib элементе MenuBar и позволяет восстанавливать фон, не заставляя приложение перерисовывать элементы своего окна. Так что в случае с прозрачным фоном в шрифте библиотеки fonts_lib.obj это будет работать куда производительней, чем попиксельный вывод. 65 функция всяко быстрее выводит чем функция 1 в цикле, а функция 36 объективней быстрее чем 35 в цикле.
    Поэтому в своей библиотеке я реализовал вывод шрифта как вывод картинки. Шрифт рисуется в оперативной памяти и выводится как картинка. Если выводится шрифт без фона, то удобней всего представить распакованный шрифт(или распаковываемый на лету) как маску. Значение отличное от нуля-это точка шрифта. Соответственно рисование такого шрифта(не обязательно напрямую на экране!) производится попиксельно. Вот это и имелось ввиду под фразой, "Для отрисовки шрифта без фона программа или библиотека должна выводить/накладывать шрифт попиксельно.". А чтобы маска занимала меньше места, лучше сделать её не в виде картинки, а как набор,например, 1 байтовых значений(с байтами быстрее манипулировать, чем с битами). Это и подразумевалось
    под, "В этом случае формировать его как картинку в памяти не очень выгодно, хотя и можно."
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • andrew_programmer
    Ну, что же - хорошо ты прояснил что имел ввиду. Если я не ошибаюсь, то у <Lrz> как раз так оно и задумано. Впрочем наверняка утверждать не стану - сам расскажет если захочет.

    Насчет 8 и 16 бит все конечно кажется логичным, но сдается мне таких видеокарт уже давно не выпускают, а те которые существуют в ближайшие годы так или иначе могут выйти из строя по причине износа (тепловые деформации и окисление никто не отменял), т.е. их количество стремительно сокращается.
    Возникает вопрос - а нужно ли заниматься этим? Не будет ли это пустой тратой времени и сил?
    Я никому конечно не хочу навязывать такой взгляд, просто обозначаю одну из логичных версий.
    ИМХО имея в своем распоряжении 24 бит или 32 бита пользователь не станет искусственно снижать до 8 и 16 бит. Даже моя старая карточка ATI Rage XL 8 Мб держала под все доступные разрешения глубину в 24 бита, да там были и 16 и 8 битные разрешения, но смысл их использовать? Они оставлены исключительно ради совместимости со старыми программами которые не могли работать с режимами больше 16 и 8 бит. И мне так кажется еще один скачок и NVidia с AMD просто откажутся от такой бесполезной совместимости. Тогда будем иметь очередной мартышкин труд.

    Те же усилия логичней направить на реализацию не хватающих контролов, да на приложения наконец - все никак не почешемся всем сообществом видеоплеер сделать, хотя наработки есть.
  • Если видеокарта поддерживает 24 или 32 бита - это конечно хорошо. Я и сам запускал Колибри на компьютере AMD-K5 75 Mhz(75Mhz- это частота процессора) с видеокартой S3 Vesa1.2 поддерживающей 24-х битный цвет. И работала колибри там более-менее терпимо(в шестерёнках FPS=8). Но я вспомнил случай, когда один пользователь пожаловался, что не может запустить Колибри в режиме отличном от VGA, потому что его видеокарта не поддерживает 24 бита, но поддерживает 16. Хотя, если не брать в расчёт эти видеокарты из-за их малого количества, то всё нормально.

    Я считаю, что старые компьютеры - это область в которой у Колибри нет конкурентов среди десктопных операционных систем.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Одна поправка, сейчас "старыми или устаревшими" называют PC PIII или Athlon 7 и видеокарты GeForce 2 или их аналоги. Купить части или сам PC можно за символические деньги. Т.е. это означает, что видеокарта будет в состоянии держать 24 и 32 бита в VESA режиме. Поддержка 16,8, 4 битных режимов практически не оправдана. Я не буду писать код который будет поддерживать эти режимы.
  • Одна поправка, сейчас "старыми или устаревшими" называют PC PIII или Athlon 7 и видеокарты GeForce 2 или их аналоги.
    Моё последнее сообщение не очень по теме.
    В университете, где я учился, было немало компьютеров Pentium I, но 24 бита их видеокарты держали. В силу проблем с финансами закупать более новые компьютеры небыло возможности и использовались все имеющиеся компьютеры(т.е. Pentium I и другие). Более-менее новые компьютеры(типа Pentium 4) были, только их было мало и они использовались в основном для оформления документов или стояли на спектрометрах или минидифрактометрах для снятия спектров.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Библиотека следующей версии + исходники. Cобирать fasm v 1.68
    Attachments
    font_lib.7z (18.38 KiB)
    Downloaded 399 times
  • вот мой вариант библиотеки для работы со шрифтами.
    работает с растровыми шрифтами формата psf.
    рекомендуется при использовании библиотеки gb_lib.
    Attachments
    psf_font-0.1.zip (16.53 KiB)
    Downloaded 524 times
  • Who is online

    Users browsing this forum: Bing [Bot] and 2 guests