Какие на данный момент есть наиболее приоритетные задачи?
-
IgorA, чем не устраивает fontslib? (см. SVN)
Тем что элемент t_edit находится в библиотеке box_lib а fontslib это также библиотека. Получается что для использования шрифта мне нужно подключать из box_lib другую библиотеку fontslib. Просто не очень внушает доверие то что получается одна библиотека будет попутно грузить другую. Я знаю что это возможно и что работать будет, просто не хочется сильно накручивать.maximYCH wrote:чем не устраивает fontslib?
И в этом есть еще один не красивый момент, все элементы из box_lib автоматически станут зависимыми от библиотеки fontslib, даже при условии что они ее не используют. Как результат возможная перепись многих программ.
MaximYCH
Кроме размера и структурной сложности, есть еще очень важный фактор: скорость.
Системные шрифты рисуются гораздо гораздо быстрее, чем библиотечные.
И при этом имеют большой резерв для оптимизации как по скорости, так и по размеру.
У библиотечных шрифтов таких резервов нет.
Кроме размера и структурной сложности, есть еще очень важный фактор: скорость.
Системные шрифты рисуются гораздо гораздо быстрее, чем библиотечные.
И при этом имеют большой резерв для оптимизации как по скорости, так и по размеру.
У библиотечных шрифтов таких резервов нет.
Если кто-нибудь интегрирует код из fontslib в ядро (dtext в gui/font.inc и компания) и скинет мне измененный код font.inc то я попробую переделать существующие приложения на своей машине (в случае удачи - выложу образ с исправленными координатами вывода в программах). Кода там совсем немного, но моего скилла не хватает (спотыкался на всяких непонятных вещах и в итоге бросил).
Имею ввиду, если вместо использования char.mt (FONT_I) будет использоваться font01.ksf при выводе через соответствующую сисфункцию.
Имею ввиду, если вместо использования char.mt (FONT_I) будет использоваться font01.ksf при выводе через соответствующую сисфункцию.
Интеграция кода библиотеки в ядро! Это шедеврально! Вилле нервно курит в сторонке, полный зависти.
Марат, а какая разница-то? Принцип отображения то один и тот же, оба берут шрифт из внешнего файла, только у одного файла - один формат, у другого - второй, вот и все.
А потому что - зачем? Битмапы будут рисоваться в ядре почти так же быстро, как и снаружи. Diamond заоптимизировал 65-ю функцию так, что крыша отъезжает.
Никакого резерва развития у битмапных шрифтов нет, остается только векторизация.
Никакого резерва развития у битмапных шрифтов нет, остается только векторизация.
maximYCH
Дело не в формате шрифта - хотя единообразие помогает уменьшить размер кода, а в том что код изначально писался как библиотечный его придется переделывать немало. Ну, и плюс его автор Алексей, уж никак не ожидал обратной тенденции -он даже 47 функцию предлагал выносить из ядра.
Дело не в формате шрифта - хотя единообразие помогает уменьшить размер кода, а в том что код изначально писался как библиотечный его придется переделывать немало. Ну, и плюс его автор Алексей, уж никак не ожидал обратной тенденции -он даже 47 функцию предлагал выносить из ядра.
С первой частью не соглашусь - можно, и я выше приводил пример как можно сделать малой кровью. Ну, а насчет векторных - их тащить в ядро еще хуже. Ты же сам ратуешь за минимализм.art_zh wrote:Никакого резерва развития у битмапных шрифтов нет, остается только векторизация.
Потому что шрифт из font01.ksf значительно более читаем.art_zh wrote:А потому что - зачем? Битмапы будут рисоваться в ядре почти так же быстро, как и снаружи. Diamond заоптимизировал 65-ю функцию так, что крыша отъезжает.
Никакого резерва развития у битмапных шрифтов нет, остается только векторизация.
Да я и сам всеми руками за вынос всего GUI/VESA из ядра, но сейчас мы имеем то, что имеем (нет, если у кого-то идет работа по их выносу оттуда - я свое предложение снимаю за бесполезностью).Mario wrote:Дело не в формате шрифта - хотя единообразие помогает уменьшить размер кода, а в том что код изначально писался как библиотечный его придется переделывать немало. Ну, и плюс его автор Алексей, уж никак не ожидал обратной тенденции -он даже 47 функцию предлагал выносить из ядра.
Марат, там 200 строк кода, неужели опытный разработчик не перенесет его за пару часов?
Если уж что-то тащить в ядро - только при условии если оно там будет работать быстрее и весить меньше чем то, что было.
Ага, т.е. на глаза юзеров и просто на удобство плевать?
Можешь не верить, но утрясание всех тонкостей и вылавливание багов займет гораздо больше времени, вероятно на порядок.maximYCH wrote:Марат, там 200 строк кода, неужели опытный разработчик не перенесет его за пару часов?
Векторные не значит медленные. Тем более их можно при загрузке растрировать, и дальше скорость будет такая же, как у битмапов.
Блин, да что ты в бутылку опять лезешь? - не плевать!maximYCH wrote:Ага, т.е. на глаза юзеров и просто на удобство плевать?
У меня уже у самого глаза сели от этого безобразия. Работаю.
Только надо не халтуру гнать, а делать всё по-уму.
Растровые - значит медленные.Sorcerer wrote:Векторные не значит медленные. Тем более их можно при загрузке растрировать, и дальше скорость будет такая же, как у битмапов.
Векторные (без растеризации) быстрее и компактнее.
Who is online
Users browsing this forum: No registered users and 0 guests