Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс апр 30, 2017 4:04 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 44 сообщения ]  На страницу Пред. 1 2 3
Автор Сообщение
СообщениеДобавлено: Пт июл 10, 2015 12:39 am 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1125
CleverMouse писал(а):
Проверка углов будет давать видимые артефакты - при перекрытии окна другим части символов, которые должны быть видимы, исчезнут.
Это как раз легко исправить, но есть проблемы посложнее. Конечно, их легко решить с помощью ctrl-c/ctrl-v, но сколько тогда кода получится... Просто мне не хочется возится с двумя координатами, и так регистров мало. И хочется унифицировать код: вывод на экран, вывод без проверок, вывод в буфер.
А что, если в первом случае тоже выводить в буфер, а потом как битмап? Изображения наверно быстрее рисуются?


Вернуться к началу
СообщениеДобавлено: Пт июл 10, 2015 5:13 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1591
Вывод в буфер в сисфункции вообще-то откровенно лишний, его вполне может делать приложение/библиотека самостоятельно, при таком вызове наверняка большая часть времени уходит на собственно системный вызов вместо работы. Марат, типично, сделал "как проще".

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


Вернуться к началу
СообщениеДобавлено: Пт июл 10, 2015 9:31 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1125
Не понял... У вас же так рисуются шрифты под иконками, сначала в буфер а потом какой-то cel shading.


Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 9:19 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Pathoswithin
Тень делается просто. Сначала темный текст, потом светлый со смещением влево-вверх на пиксель.
А отрисовка в пользовательский буфер это жуткий костыль.


Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 5:24 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1125
Всё равно не понял, почему жуткий костыль? Как это сделать по другому, если пользовательская программа хочет применить к шрифту свой эффект?
И скажите что-нибудь про скорость вывода изображений.


Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 6:28 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пт апр 17, 2015 9:44 am
Сообщения: 29
Pathoswithin, f.73 выводит 32 битное изображение практически с той же скоростью, что и SetDIBitsToDevice в винде


Вернуться к началу
СообщениеДобавлено: Вс июл 12, 2015 9:41 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1125
А f.65?


Вернуться к началу
СообщениеДобавлено: Пн июл 13, 2015 4:06 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1591
Pathoswithin писал(а):
Всё равно не понял, почему жуткий костыль?
Потому что на ровном месте появляется системный вызов, что а) тормозит и б) раздувает ядро.
Pathoswithin писал(а):
Как это сделать по другому, если пользовательская программа хочет применить к шрифту свой эффект?
Самостоятельно вывести в буфер так, как ей надо. Это не настолько сложный процесс, чтобы дёргать ради него ядро. Будет быстрее.

Pathoswithin писал(а):
И скажите что-нибудь про скорость вывода изображений.
В дистрибутиве есть бенчмарк графики mgb.

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

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


Вернуться к началу
СообщениеДобавлено: Пн июл 13, 2015 5:05 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1125
Цитата:
Самостоятельно вывести в буфер так, как ей надо. Это не настолько сложный процесс, чтобы дёргать ради него ядро. Будет быстрее.
Стоп, ещё раз. Программа хочет вывести строку текста так, чтобы она по длине переливалась из одного цвета в другой, системными шрифтами, которые имеют недокументированную структуру и вшиты в ядро. Поэтапно, как она будет это делать?
Цитата:
Откуда буфер возьмёшь? Ядерный стек потока не резиновый
При чём здесь стек? kernel_alloc для всей строки, не? Мне ж его другой функции скармливать.


Вернуться к началу
СообщениеДобавлено: Пн июл 13, 2015 7:24 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1591
Pathoswithin писал(а):
Цитата:
Самостоятельно вывести в буфер так, как ей надо. Это не настолько сложный процесс, чтобы дёргать ради него ядро. Будет быстрее.
Стоп, ещё раз. Программа хочет вывести строку текста так, чтобы она по длине переливалась из одного цвета в другой, системными шрифтами, которые имеют недокументированную структуру и вшиты в ядро. Поэтапно, как она будет это делать?
В чём проблема? Формат совершенно тривиальный, никто не мешает скопировать себе char.mt или char2.mt и вообще не связываться с ядром.
Pathoswithin писал(а):
Цитата:
Откуда буфер возьмёшь? Ядерный стек потока не резиновый
При чём здесь стек? kernel_alloc для всей строки, не? Мне ж его другой функции скармливать.

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

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


Вернуться к началу
СообщениеДобавлено: Пн июл 13, 2015 8:57 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1125
Цитата:
В чём проблема? Формат совершенно тривиальный, никто не мешает скопировать себе char.mt или char2.mt и вообще не связываться с ядром.
А, ну правильно, зачем нам вообще ядро? Программа вполне в состоянии всё делать самостоятельно, рисовать окно и кнопки, отслеживать клавиатуру и мышь. Ну разве что спрашивать, кому принадлежит точка экрана, и то могут друг с другом общаться: "Не твоя точка, не? И не твоя? Ну я нарисую, вы не против?". А ядро не трогать, оно по статусу имеет право ничего не делать.
Кстати, TinyPad близок к этому идеалу. Правда, там говна больше чем кода... в отличии от TextEdit.
Цитата:
Дёргать kernel_alloc, оперирующую страницами, ради 216 байт, расточительно.
216 байт это только один символ, и то при х8 уже понадобится 4 страницы.


Вернуться к началу
СообщениеДобавлено: Вт июл 14, 2015 3:10 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1591
Pathoswithin писал(а):
Цитата:
В чём проблема? Формат совершенно тривиальный, никто не мешает скопировать себе char.mt или char2.mt и вообще не связываться с ядром.
А, ну правильно, зачем нам вообще ядро? Программа вполне в состоянии всё делать самостоятельно, рисовать окно и кнопки, отслеживать клавиатуру и мышь. Ну разве что спрашивать, кому принадлежит точка экрана, и то могут друг с другом общаться: "Не твоя точка, не? И не твоя? Ну я нарисую, вы не против?". А ядро не трогать, оно по статусу имеет право ничего не делать.
Программа не может отслеживать клавиатуру и мышь, потому что программа не одна в системе, а клавиатура и мышь - общие устройства. Более того, доступ к железу - привилегированная операция, и десктопная система - а я пишу десктопную систему - не может давать прямой доступ к железу кому попало, здесь ядро нужно.

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

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


Вернуться к началу
СообщениеДобавлено: Вт июл 14, 2015 3:38 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
б+) все программы честно используют read-write блокировку карты окон. И не забывают освобождать блокировку в конце отрисовки.


Вернуться к началу
СообщениеДобавлено: Вт июл 14, 2015 6:36 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1125
Вложение:
jesus.PNG
jesus.PNG [ 26.57 КБ | 998 просмотров ]
Понял, шутить здесь бесполезно...


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 44 сообщения ]  На страницу Пред. 1 2 3

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB