Board.KolibriOS.org

[ядерный]

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

maximYCH wrote:Насколько я помню, были стремления вынести графическую подсистему из ядра, а не вбухивать в ядро ещё больше всего и вся.

Стремления у кого-то, как мне припоминается, были. А ядерные GUI-функции и ныне там.
И работают они очень шустро именно потому, что они ядерные.
Может кто знает как их заставить крутиться еще быстрее, но при этом вынуть GUI-код из ядра? -- я не знаю !!
А вот как их упорядочить, ускорить и уменьшить, оставив в ядре - это достаточно понятно.

А я расскажу, как сделать. Точнее об этом когда-то говорил diamond, я просто повторюсь.
С какой стати ЯДРО проверяет необходимость обработать в каждой подсистеме (я про osloop), а не имеет буфер, в который любой драйвер может отправить запрос на обработку? Ведь по факту, если в остальных подсистемах ничего не произошло, кроме графической подсистемы, то графика ждет, пока ядро проверит наличие действий на обработку в каждой подсистеме, вместо того, чтобы сразу сообщения от гр. подсистемы было обработано?
--> нужно выносить подсистемы в драйвера
--> нужно переписывать драйверную модель и в osloop проверять только наличие новых сообщений в буфере на обработку событий.

maximYCH wrote:А я расскажу, как сделать. Точнее об этом когда-то говорил diamond, я просто повторюсь.
С какой стати ЯДРО проверяет необходимость обработать в каждой подсистеме (я про osloop), а не имеет буфер, в который любой драйвер может отправить запрос на обработку?

Osloop-то здесь при чем ?
Для справки: ядро сейчас отрабатывает отдельные GUI-запросы индивидуально, через системный сервис int40h. (функции 1,4,7,13-15,35-39,47,48,50,61 и 65)
Все понимают, что это неэффективная трата ресурсов. Но оно работает, причем быстрее чем Винда с аппаратным ускорителем.
Может ли оно работать еще быстрее? - да, может.

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

maximYCH wrote:Ведь по факту, если в остальных подсистемах ничего не произошло, кроме графической подсистемы, то графика ждет, пока ядро проверит наличие действий на обработку в каждой подсистеме, вместо того, чтобы сразу сообщения от гр. подсистемы было обработано?

Вот в этом словоизвержении я нифига не понял: ты это про что и вместо чего?

maximYCH wrote:--> нужно выносить подсистемы в драйвера

А можно и не выносить.
Смотря какие подсистемы, и зачем.

maximYCH wrote:--> нужно переписывать драйверную модель и в osloop проверять только наличие новых сообщений в буфере на обработку событий.

При чем здесь драйверная модель вообще
Сейчас osloop графикой вообще не занимается (мышиная возня не в счет).
Ты его хочешь подключить к обработке очередей GUI-запросов.
И это будет "вынос GUI из ядра" ?!.

Ты его хочешь подключить к обработке очередей GUI-запросов.
И это будет "вынос GUI из ядра" ?!.

Вынести GUI из ядра для меня равносильно вынести ВСЕ что касается графики и оконной подсистемы в связку драйвера+библиотеки и освободить ядро от знания того, что есть графика и окна.

Максим, а давай ты сам возьмешь и вынесешь? Прямо вот так своими собственными пальцами в текстовом редакторе? Это же не сложно, не сложней чем комментарии на IT ресурсах писать. Мы не возражаем - честное пионерское (меня в пионеры принимали и я не выходил из организации сам)! Давай уже начинай! Такой умный и креативный человек и чего зря время теряешь?

По сути maximYCH прав. Разговор давно шёл о том чтобы вынести код оконной системы в отдельный модуль. А то сейчас там слишком всё перемешано.

Serge
Не надо все валить в одну кучу - оконный менеджер, GUI и тут еще и osloop откуда-то приперся.

Оконный интерфейс имхо более-менее компактно лежит в window.inc, а его интерактивная часть - в mouse.inc.
GUI на 70% оформлена в VESA20.inc, плюс небольшой кусочек в kernel.asm; шрифты - там где им положено.

Настоящая мешанина - в сисфункциях GUI, так уж исторически сложилось. И еще экранная карта у нас проверяется в 20 разных местах, везде с одной целью и везде по-своему. Потому что всем проще перемножить X на Y, чем вызывать единообразную процедуру как положено.

Разобраться во всем этом добре и привести его в порядок не так уж сложно. Гораздо проще, чем городить новый огород.

art_zh
Компактность эта очень условна. Структуры потоков, окон и планировщика перемешаны. Данные размазаны по всей памяти. Посмотри для примера старое определение twdw.

Serge
"Чем этих отмыть - легче новых нарожать" - так, что ли?

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

Mario
При всей свободе самовыражения, существует некая генеральная линия, с которой (как потом оказывается) "все согласились".

"Все согласились, что GUI надо выносить из ядра".
- я не соглашался.

Систему (ядро+драйверы+структуры данных) надо делать компактнее, надежнее и быстрее.
Вынос GUI может привести совсем в другую сторону.

Вынести гуй и переписать его на Си. ^__^

art_zh

"Чем этих отмыть - легче новых нарожать" - так, что ли?

Таки да. Некоторым товарищам GUI вообще не нужно. Разговор шел о том, что если вносить серьёзные изменения в диспетчер окон -

• произвольное количество окон
• отрисовка элементов GUI в user-mode
• отрисовка в битмап
• использование акселерации
• тайловая архитектура
• композитный менеджер

то желательно сделать всё это в виде отдельного модуля. Это пойдёт на пользу как ядру так и менеджеру. Делать это (отдельный модуль) просто ради "шоб було" не зачем.

А можно заменить ядро на Линукс и использовать X сервер как нормальные люди.