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

Thu Aug 03, 2006 9:06 am

Решил я тут немного расширить возможности вывода обычного шрифта и начал делать масштабирование, но встретился с такой проблемой: если окно находится в координатах 0:0, то все отлично, но стоит сдвинуть окно, как шрифт начинает все дальше уползать от нужного месторасположения. Выкладываю тут скрины и то, что я переделал в font.inc. Кто знает в чем проблема?

Смещаем окно:

Код(из 0530):
http://knikolenko.narod.ru/kolibri/font.inc

Thu Aug 03, 2006 9:33 am

Координаты окна 2 раза прибавляются к глобальным координатам строки текста.

Thu Aug 03, 2006 9:38 am

А может drawbar рисуется от оконых координат, а putpixel-экранных?

Попробывал делить координаты Х и У на 2 не помогло

Thu Aug 03, 2006 1:06 pm

Все сделал. Спасибо всем кто помогал.
Размер передается вместе с цветом например 0x02000000 выведется текст черного цвета в два раза больше обычного размера. Пока что сделан только моноширинный шрифт.
Вот код процедур измененнных в font.inc

SizeFont dd 1
align 4
mydrawbox:
pusha
mov esi,[SizeFont]
mov edi,[SizeFont]
.drpix:
call [putpixel]
inc eax
dec edi
jnz .drpix
sub eax,[SizeFont]
inc ebx
mov edi,[SizeFont]
dec esi
jnz .drpix
popa
ret

align 4
dtext: ; Text String Output (rw by Johnny_B[john@kolibrios.org])
; eax x & y
; ebx font ( 0xX0000000 ) & color ( 0x00RRGGBB )
; ecx start of text
; edx length
; edi 1 force

pushad

mov esi,edx ;esi=length
mov ebp,ecx ;ebp=ptr to text
mov ecx,ebx ;ecx=color
movzx ebx,ax ;ebx=y
shr eax,16 ;eax=x
and esi, 0xFF ;limit of text = 255 symbols

push ecx
shr ecx,24
and ecx,0x0F
test ecx,ecx
jne .dalee
mov ecx,1
.dalee:
mov [SizeFont],ecx
pop ecx

dtext.lnew:
test esi, esi ; zero length ?
jnz @f
jmp dtext.output_end
@@:

movzx edx,byte [ebp] ;edx=ascii code
test edx,edx
jz dtext.output_end
test ecx,0x10000000
jnz dtext.letnew2

align 4
.letnew:

drawletter: ;output char of type 1(monotype)
;eax - x
;ebx - y
;ecx - color
;edx - ascii code
pushad
call [disable_mouse]
mov esi,9
lea ebp,[0x3F600+8*edx+edx]
.symloop:
push esi
mov dl,byte [ebp]
mov esi,8
.pixloop:
test dl,1
jz .nopix
call mydrawbox
.nopix:
shr dl,1
add eax,[SizeFont]
dec esi
jnz .pixloop
push ebx
mov ebx,8
imul ebx,[SizeFont]
sub eax,ebx
pop ebx
add ebx,[SizeFont]
inc ebp
pop esi
dec esi
jnz .symloop
popad

push ebx
mov ebx,6
imul ebx,[SizeFont]
add eax,ebx
pop ebx

inc ebp ;ptr to text
dec esi ;length
jnz dtext.lnew

jmp dtext.output_end

dtext.letnew2:

Fri Oct 31, 2008 10:42 am

Предлагаю в качестве расширения системных шрифтов использовать следующий подход:
Я пишу библиотеку, которая позволяет выводить шрифт с таким интерфейсом:
- кидаем в стек указатель на строку, указываем цвета фона и текста, указываем куда выводить.
Пользоваться можно будет как из ассеблерных программ,так и из С. либа будет поддерживать такие вызовы.
пример использования шрифта 8х16 приведен во вложении. Для вывода ширифта используется 65 функция.

Fri Oct 31, 2008 10:53 am

Как раз последние два дня думаю чтобы такое сделать со шрифтами в Колибри чтобы они стали больше

Да... 1. Можно будет испольовать только этот шрифт или любой?
2. Как там со скоростью вывода шрифтов? Намного медленнее, чем обычных?

Fri Oct 31, 2008 11:18 am

Leency
Re:
1. Можно будет использовать любой шрифт который будет в библиотеке.
2. Кто-нибудь жаловался на скорость отрисовки kfar или console? Подход один и тот же.
Чем больше нужно будет отображить на экране текстовой информации, тем этот подход будет быстрее работать чем вывод 2 системных шрифтов. Т.е. при выводе картинки - выводиться она только 1 раз и сразу заполняет область канвы приложения. Системные шрифты обрабатывают каждый символ в отдельности, чем больше букв, тем медленнее работают системные втроенные в ядро шрифты.

Еще у меня вопрос, как много людей хотят или планируют использовать такой подход при написании/переписывании приложений?

Fri Oct 31, 2008 12:50 pm

Рад буду изменить для этого Tinypad, однако нужно будет ещё две функции, возвращающие ширину и высоту заданного текста. Плюс, возможность рисовать без заливки фона (м?), хотя это не особо обязательно (не помню уже, как там у меня было реализовано).

Fri Oct 31, 2008 12:53 pm

Хотелось бы иметь возможность указывать свои шрифты. А так же возможность передать библиотеке callback функцию для создания изображения (глифа) символа, которая вызывается библиотекой при необходимости. Если библиотека будет брать шрифты по именам из некой общей системной директории, будет замечательно. Перенос слов. Расчет размера области вывода с учетом переноса. Вывод текста на bitmap (в память). Области обрезания отрисовки (clipping). Прозрачный фон. Прозрачные символы. Градиент вместо цвета. Callback вместо цвета. И т.д.
Библиотека безусловна нужна, но если её делать, то пусть она будет функционально совершенна :-). А сделать просто вывод битового шрифта каждый может и сам в своём проекте, это не так уж сложно. Хотя, конечно, не всё сразу.

..bw

Fri Oct 31, 2008 12:58 pm

безусловно, буду использовать

Fri Oct 31, 2008 1:30 pm

mike.dld
Поскольку изображение формируется в озу то это можно будет сделать.
Рисование без заливки фона с этим сложнее т.к. для этого нужно иметь как минимум 2 копии области куда будет рисовататься, что бы применить наложение (у меня есть примеры использования mmx команд). Т.е. наложение будет возможно только если вывод будет полностью управляться библиотекой.

bw
Да, это будет сделано, шрифты можно будет выбирать, как по размеру, так и по типу. Папка FONT уже существует. Конечно шрифты должны быть специально для этого подготовлены. Можно сделать функцию которая будет возвращать указатель на глиф.
На счет переноса слов, эм.. имхо этим должна заниматься не библиотека шрифтов. Допустим будет написана функция которая будет грамотно переносить слова и разделять общий текст на строчки спец символами. Если это будет сделано, можно отобразить корректно текст в при динамическом изменении окна. Хм. вывод текства в память ? Фактически он уже в памяти - можно возращать указатель на начало блока и размер блока т.е. текст преобразован в глифы и имеет массив. На счет прозрачности, я уже писал выше, только при наличии полного управления выводом. Т.е. если раньше что-то было на канве приложения и это не формировалось либой, оно будет затерто. Градиент, то же возможно реализовать, но не сразу.

Code: Select all

Callback вместо цвета

О_о это как это *?

А сделать просто вывод битового шрифта каждый может и сам в своём проекте, это не так уж сложно.

За всю истрорию Коос, это сделали единицы, и только для своих проектов. к примеру kfar.
Конечно может Serge или кто -то еще и прикрутит шрифты от иксов, но я думаю без аппаратной акселерации это будет медленно.
Фактически это простой способ получить конечному приложению возможность управлять шрифтами. Этот подход не лишен недостатков, т.к. потребности в ОЗУ значительно возрастают. К примеру шрифт 8х16 после обработки у меня занимает 4096 байт. При реализации хотя бы 50 % от озвученного потребуется области ОЗУ ~300 -900 кб. И такая картина будет для каждого приложения которое будет использовать эту библиотеку.
При рациональном использовании можно сократить объем используемого ОЗУ до 20 -50 Кб.

Fri Oct 31, 2008 2:18 pm

> Т.е. наложение будет возможно только если вывод будет полностью управляться библиотекой.

Ну а почему не выводить глиф, в таком случае, попиксельно. Я полагаю что ты планируешь его отрисовывать целиком?

>> Callback вместо цвета
> О_о это как это *?

При выводе (x, y) точки глифа, вызывается пользовательская функция для получения цвета. Это избавит тебя от, скажем, реализации градиента, а пользователю твоей библиотеки позволит реализовавывать разнообразные эффекты. Этот callback может вызываться каждый раз при выводе глифа, тогда решится проблема с прозрачность, в том числе с альфой :-). Или он будет вызываться только при построении глифа, а дальше используется только этот кешированный результат.

p.s. Прозрачность нужна обязательно.

..bw

Fri Oct 31, 2008 2:23 pm

Может быть реализовать как-то более чем просто библиотеку? Может быть на функцию ядра? Так было бы и проще и быстрее.
Использовать, конечно, буду

Fri Oct 31, 2008 2:32 pm

Уже давно согласились, что функции GUI в ядре, это не хорошо. А ты предлагаешь вернуться к тому, от чего пытаемся отойти.

..bw

Fri Oct 31, 2008 2:49 pm

bw
При выводе (x, y) точки глифа, вызывается пользовательская функция для получения цвета. Это избавит тебя от, скажем, реализации градиента, а пользователю твоей библиотеки позволит реализовавывать разнообразные эффекты. Этот callback может вызываться каждый раз при выводе глифа, тогда решится проблема с прозрачность, в том числе с альфой . Или он будет вызываться только при построении глифа, а дальше используется только этот кешированный результат.

Функция 65 заточена на вывод целиком изображения, сейчас попиксельно выводиться системные шрифты, как ты знаешь на больших объемах это тормоза. А ты предлагаешь венуться, к тому от чего хочется уйти.
Теперь представим ситуацию, к примеру в глиф 8х16 - итого 128 точек для каждой точки ты предлагаешь вызывать callback для получения цвета пикселя. на 1 символ 128 вызовов.
для вывода текста длинной 200 символов тебе потребуется 200х128=25600 раз вызвать функцию для получения цвета. На машинах ниже PIII это будет видно глазу. И кто будет использовать это? Т.е. если это и реализовывать то только при аппаратной акселерации.
Далее при формировании градиента возможны тормоза при выводе, или увеличению использования ОЗУ(градиент будет сформирован для всего изображения в ОЗУ). Формирование прозрачности и наложения, конечно можно реализовать через прямой доступ к видеобуферу, но этот способ аппаратно зависим. Т.е. при появлении драйверов к видеокарточке может и не работать. Т.е. лучше иметь доступ к буферу через метод реализуемый драйвером.

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

Who is online