Board.KolibriOS.org

CleverMouse wrote:Проверка углов будет давать видимые артефакты - при перекрытии окна другим части символов, которые должны быть видимы, исчезнут.

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

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

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

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

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

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

А f.65?

Pathoswithin wrote:Всё равно не понял, почему жуткий костыль?

Потому что на ровном месте появляется системный вызов, что а) тормозит и б) раздувает ядро.

Pathoswithin wrote:Как это сделать по другому, если пользовательская программа хочет применить к шрифту свой эффект?

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

Pathoswithin wrote:И скажите что-нибудь про скорость вывода изображений.

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

Pathoswithin wrote:А что, если в первом случае тоже выводить в буфер, а потом как битмап?

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

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

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

Откуда буфер возьмёшь? Ядерный стек потока не резиновый

При чём здесь стек? kernel_alloc для всей строки, не? Мне ж его другой функции скармливать.

Pathoswithin wrote:

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

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

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

Pathoswithin wrote:

Откуда буфер возьмёшь? Ядерный стек потока не резиновый

При чём здесь стек? kernel_alloc для всей строки, не? Мне ж его другой функции скармливать.

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

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

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

Дёргать kernel_alloc, оперирующую страницами, ради 216 байт, расточительно.

216 байт это только один символ, и то при х8 уже понадобится 4 страницы.

Pathoswithin wrote:

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

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

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

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

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

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