Quote:
З.Ы. Андрей не обижайся на мое высказывание, но не стоит торопится, за это время разработка системы совсем на месте не стояла, как это может показаться с первого взгляда.
Разве я когда-то обижался?
Всё, что делается в Колибри - всё к лучшему.
Quote:
А может все-таки не надо валить все в одну кучу? Мы только-только отходим от принципа "все в GUI ядра" (причем в некоторых случаях этот отход был психологически болезненным), а ты уже предлагаешь "А давайте все в одну библиотеку запихаем?".
Нет, всё в одну библиотеку я не предлагаю, да и нельзя всё сваливать в одну библиотеку. Я привёл пример, почему нужно сделать рисование шрифта в памяти с различным количеством бит на пиксель. Если изначально считать, что цвет точки всегда 24-х битный, то при выводе изображения в 8-ми и 16-ти битных разрешениях придётся переконвертировать нарисованный в буфере шрифт в 8 или 16 бит на пиксель. А зачем процессор мучить лишними вычислениями - пусть уж лучше сразу рисует в 8-ми или 16-ти битном цвете.
Обсуждение одной тематики оказалось тесно связано с другой, поэтому и получилось, что я как бы говорю не совсем по теме. Но тем не менее вот моя логика.
Со временем, если Колибри научиться работать в разрешениях 8 и 16 бит на пиксель, то возникнет вопрос, "А как отображать в этих режимах 24-х и 32-х битные объекты?". Не сваливать же всю проблему на ядро операционной системы, как то сейчас в VGA режиме. Значит этим должны заниматься
библиотеки работающие в user-mode. Единственные библиотеки, которые могут на себя взять эту задачу - это библиотеки GUI. Свою библиотеку я упомянул только в качестве примера и я совсем не считаю, что другие библиотеки хуже моей. Как я уже упоминал, должны быть разные библиотеки GUI, чтобы в
зависимомти от задач можно было использовать нужную библиотеку.
Quote:
Все это очень замечательно, когда все происходит на уроне ядра, где нет переходов с Ring0 на Ring3. При взаимодействии же ядра и приложения каждая точка вызывается int 0x40, что не есть правильно с точки зрения производительности.
С целью уменьшения накладных расходов, я в свое время несколько оптимизировал функцию 35, в результате получилась функция 36. Которая замечательно так используется в BoxLib элементе MenuBar и позволяет восстанавливать фон, не заставляя приложение перерисовывать элементы своего окна. Так что в случае с прозрачным фоном в шрифте библиотеки fonts_lib.obj это будет работать куда производительней, чем попиксельный вывод. 65 функция всяко быстрее выводит чем функция 1 в цикле, а функция 36 объективней быстрее чем 35 в цикле.
Поэтому в своей библиотеке я реализовал вывод шрифта как вывод картинки. Шрифт рисуется в оперативной памяти и выводится как картинка. Если выводится шрифт без фона, то удобней всего представить распакованный шрифт(или распаковываемый на лету) как маску. Значение отличное от нуля-это точка шрифта. Соответственно рисование такого шрифта(не обязательно напрямую на экране!) производится попиксельно. Вот это и имелось ввиду под фразой, "Для отрисовки шрифта без фона программа или библиотека должна выводить/накладывать шрифт попиксельно.". А чтобы маска занимала меньше места, лучше сделать её не в виде картинки, а как набор,например, 1 байтовых значений(с байтами быстрее манипулировать, чем с битами). Это и подразумевалось
под, "В этом случае формировать его как картинку в памяти не очень выгодно, хотя и можно."
Register
Login
FAQ
Search
Members
. Однако рекомендую посмотреть в сторону распространенных форматов. Т.к. в этом случае не нужно будет самостоятельно изготовлять шрифт в своем формате. Я планирую сделать простую и быструю библиотеку системных шрифтов со своим форматом. Но данная библиотека не отменяет необходимость в реализации устоявшихся форматов шрифтов.
