Board.KolibriOS.org

Это как раз легко исправить, но есть проблемы посложнее. Конечно, их легко решить с помощью ctrl-c/ctrl-v, но сколько тогда кода получится... Просто мне не хочется возится с двумя координатами, и так регистров мало. И хочется унифицировать код: вывод на экран, вывод без проверок, вывод в буфер.
А что, если в первом случае тоже выводить в буфер, а потом как битмап? Изображения наверно быстрее рисуются?

Вывод в буфер в сисфункции вообще-то откровенно лишний, его вполне может делать приложение/библиотека самостоятельно, при таком вызове наверняка большая часть времени уходит на собственно системный вызов вместо работы. Марат, типично, сделал "как проще".

_________________
Сделаем мир лучше!

Не понял... У вас же так рисуются шрифты под иконками, сначала в буфер а потом какой-то cel shading.

Pathoswithin
Тень делается просто. Сначала темный текст, потом светлый со смещением влево-вверх на пиксель.
А отрисовка в пользовательский буфер это жуткий костыль.

Всё равно не понял, почему жуткий костыль? Как это сделать по другому, если пользовательская программа хочет применить к шрифту свой эффект?
И скажите что-нибудь про скорость вывода изображений.

Pathoswithin, f.73 выводит 32 битное изображение практически с той же скоростью, что и SetDIBitsToDevice в винде

А f.65?

Потому что на ровном месте появляется системный вызов, что а) тормозит и б) раздувает ядро.
Самостоятельно вывести в буфер так, как ей надо. Это не настолько сложный процесс, чтобы дёргать ради него ядро. Будет быстрее.

В дистрибутиве есть бенчмарк графики mgb.

1. Функции вывода битмапа не умеют прозрачность.
2. Откуда буфер возьмёшь? Ядерный стек потока не резиновый, 9*6*4 байта = 216 байт там, конечно, найдётся, но если ты эти 9*6 будешь увеличивать в 8 раз по обеим осям, то перезапишешь что попало со слабопредсказуемыми эффектами.

_________________
Сделаем мир лучше!

Стоп, ещё раз. Программа хочет вывести строку текста так, чтобы она по длине переливалась из одного цвета в другой, системными шрифтами, которые имеют недокументированную структуру и вшиты в ядро. Поэтапно, как она будет это делать?
При чём здесь стек? kernel_alloc для всей строки, не? Мне ж его другой функции скармливать.

В чём проблема? Формат совершенно тривиальный, никто не мешает скопировать себе char.mt или char2.mt и вообще не связываться с ядром.

kernel_alloc - не самая быстрая функция, дёргать её на каждую строчку чревато просадкой в скорости. Количество областей памяти, выделяемых kernel_alloc, довольно ограничено, что-то порядка 4096. Дёргать kernel_alloc, оперирующую страницами, ради 216 байт, расточительно.

_________________
Сделаем мир лучше!

А, ну правильно, зачем нам вообще ядро? Программа вполне в состоянии всё делать самостоятельно, рисовать окно и кнопки, отслеживать клавиатуру и мышь. Ну разве что спрашивать, кому принадлежит точка экрана, и то могут друг с другом общаться: "Не твоя точка, не? И не твоя? Ну я нарисую, вы не против?". А ядро не трогать, оно по статусу имеет право ничего не делать.
Кстати, TinyPad близок к этому идеалу. Правда, там говна больше чем кода... в отличии от TextEdit.
216 байт это только один символ, и то при х8 уже понадобится 4 страницы.

Программа не может отслеживать клавиатуру и мышь, потому что программа не одна в системе, а клавиатура и мышь - общие устройства. Более того, доступ к железу - привилегированная операция, и десктопная система - а я пишу десктопную систему - не может давать прямой доступ к железу кому попало, здесь ядро нужно.

Разделение экрана прямо в таком виде нежизнеспособно - программа сама не знает, какие части её окна видимы, другая программа может просто висеть, переключение контекста между программами ещё медленнее, чем вызов ядра, - но отрисовка в user-mode без участия ядра в принципе возможна. При условии, что а) информация о карте окон в том или ином виде хранится где-то в расшаренной памяти, б) отрисовкой занимается общая библиотека, умеющая читать информацию из пункта а и не писать куда не просят, в) мы доверяем всем программам, что они не будут рисовать текст "ваша система заблокирована, отправьте смс на номер 1234" поверх всех остальных окон в обход библиотеки из пункта б - пункт в был бы важнее, если бы фреймбуфер не был и так открыт на запись всему миру - и, главное, г) кто-то перепишет всю-всю-всю графическую подсистему и все-все-все графические программы на такую схему.

_________________
Сделаем мир лучше!

б+) все программы честно используют read-write блокировку карты окон. И не забывают освобождать блокировку в конце отрисовки.

Понял, шутить здесь бесполезно...