Board.KolibriOS.org

Official KolibriOS board
It is currently Wed May 22, 2019 10:29 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 134 posts ]  Go to page Previous 15 6 7 8 9
Author Message
PostPosted: Thu Sep 15, 2011 10:04 pm 
art_zh wrote:
Растровые - значит медленные.
Векторные (без растеризации) быстрее и компактнее.

Разве мы уже не исследовали в свое время скорость случайной и последовательной записи в видеопамять. Чем обосновывается первое утверждение?


Top
   
PostPosted: Thu Sep 15, 2011 10:11 pm 
Offline
User avatar

Joined: Mon Oct 27, 2008 10:10 pm
Posts: 811
Более детально посмотрел на fontslib, выводы:
1) получается что либо нужно впихивать все функции в box_lib, или давать ссылку на функцию font_draw_on_string из внешней программы
2) шрифты ограничены размером 8*16 :
Code:
       push dword (8 shl 16 +16)   ; поиск нужного шрифта в наборе шрифтов (пока доступен только 8х16)
       call [get_font]


Top
   
PostPosted: Thu Sep 15, 2011 10:28 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1328
Mario wrote:
art_zh wrote:
Растровые - значит медленные.
Векторные (без растеризации) быстрее и компактнее.

Разве мы уже не исследовали в свое время скорость случайной и последовательной записи в видеопамять. Чем обосновывается первое утверждение?

Растеризованный битмап 8х16 = это (минимум!) 128 пикселей в любом символе.
Даже в пробеле.
Векторные цепочки пикселей будут выводиться гораздо быстрее. Просто потому что реальных пикселей в тексте - почти в 10 раз меньше.


Top
   
PostPosted: Thu Sep 15, 2011 10:40 pm 
art_zh wrote:
Растеризованный битмап 8х16 = это (минимум!) 128 пикселей в любом символе.
Даже в пробеле.
Векторные цепочки пикселей будут выводиться гораздо быстрее. Просто потому что реальных пикселей в тексте - почти в 10 раз меньше.

Если тупо выводить, то да, но текущие растровые системные шрифты выводятся попиксельно, ничего не мешает выводить попиксельно и новые.
Векторные шрифты без растрирования налагают дополнительную множественную математическую обработку, а с растрированием получается то же самое что и растровые. Никто ведь не собирается по тупому выводить. Пробел при прочих условиях вообще не нужно рисовать, разве что идет вывод шрифта с фоном.


Top
   
PostPosted: Thu Sep 15, 2011 11:07 pm 
У меня есть компромиссное предложение:
1. Чтобы не переписывать кучу программ пусть вывод остается функцией 4 (Ring3 овцы целы?), но при выборе третьего шрифта ядро переадресовывает обработку на заранее установленный обработчик вызывающий код нового шрифта.
2. Допустим с помощью дополнительной функции ядра мы устанавливаем указатель на загруженную библиотеку, которая рисует новые шрифты. Я не уверен насчет всех компонентов Box_Lib, но те которые писал я содержат поля в структурах данные, для оперирования размером шрифта. Так что доработать, чтобы оно было "прозрачным" для старых приложений не накладно.
3. Можно библиотеку сделать в виде подгружаемого драйвера (Ring0 волки сыты?) - важно лишь чтобы не было дублирования растрированных шрифтов, чтобы не кушать зазря память.


Top
   
PostPosted: Fri Sep 16, 2011 12:18 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
А что мешает сделать новый системный вызов ?


Top
   
PostPosted: Fri Sep 16, 2011 12:20 am 
Serge wrote:
А что мешает сделать новый системный вызов ?

Необходимость более масштабного переписывания кода компонентов Box_Lib в моем случае.


Top
   
PostPosted: Fri Sep 16, 2011 9:09 am 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
Моя идея максимально проста: есть текущая реализация 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.


Top
   
PostPosted: Fri Sep 16, 2011 10:03 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario
Переписывать всё равно придётся. Потому что опять предлагается костыль.


Top
   
PostPosted: Fri Sep 16, 2011 1:27 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
maximYCH, часто программисты используют 4ю функцию и подразумевают, что ширина и высота шрифта строго определенные. После изменения размеров системных шрифтов 90% (ну или несколько меньше) программ с GUI придется все равно переписывать. Заодно желательно закладывать в них возможность работы на сверхвысоких разрешениях (т.е. на высоких dpi) - чтобы иконки и кнопки не были очень маленькими.


Top
   
PostPosted: Fri Sep 16, 2011 1:49 pm 
Serge wrote:
Mario
Переписывать всё равно придётся. Потому что опять предлагается костыль.

Иконки помнишь? Буфер обмена помнишь?... Прошло полгода: Шрифты помнишь? :cry:


Top
   
PostPosted: Fri Sep 16, 2011 1:52 pm 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
Sorcerer wrote:
maximYCH, часто программисты используют 4ю функцию и подразумевают, что ширина и высота шрифта строго определенные. После изменения размеров системных шрифтов 90% (ну или несколько меньше) программ с GUI придется все равно переписывать.

и
maximYCH wrote:
я согласен исправить координаты вывода в существующих программах

По-моему это про одно и то же ;)


Top
   
PostPosted: Fri Sep 16, 2011 1:55 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Одними координатами вывода не обойтись. Нужно менять абсолютно всю GUI-часть. Алгоритмы расчета высоты panel, меню-баров в animage и tinypad, расположение кнопок. Это не на день и не на два работы.


Top
   
PostPosted: Fri Sep 16, 2011 1:59 pm 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
А кто-то спорит? Я ведь ничего не упоминал о сроках.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 134 posts ]  Go to page Previous 15 6 7 8 9

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited