Насколько я помню, были стремления вынести графическую подсистему из ядра, а не вбухивать в ядро ещё больше всего и вся.[ядерный]
Опять про X и Linux
Стремления у кого-то, как мне припоминается, были. А ядерные GUI-функции и ныне там.maximYCH wrote:Насколько я помню, были стремления вынести графическую подсистему из ядра, а не вбухивать в ядро ещё больше всего и вся.
И работают они очень шустро именно потому, что они ядерные.
Может кто знает как их заставить крутиться еще быстрее, но при этом вынуть GUI-код из ядра? -- я не знаю !!
А вот как их упорядочить, ускорить и уменьшить, оставив в ядре - это достаточно понятно.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
А я расскажу, как сделать. Точнее об этом когда-то говорил diamond, я просто повторюсь.
С какой стати ЯДРО проверяет необходимость обработать в каждой подсистеме (я про osloop), а не имеет буфер, в который любой драйвер может отправить запрос на обработку? Ведь по факту, если в остальных подсистемах ничего не произошло, кроме графической подсистемы, то графика ждет, пока ядро проверит наличие действий на обработку в каждой подсистеме, вместо того, чтобы сразу сообщения от гр. подсистемы было обработано?
--> нужно выносить подсистемы в драйвера
--> нужно переписывать драйверную модель и в osloop проверять только наличие новых сообщений в буфере на обработку событий.
С какой стати ЯДРО проверяет необходимость обработать в каждой подсистеме (я про osloop), а не имеет буфер, в который любой драйвер может отправить запрос на обработку? Ведь по факту, если в остальных подсистемах ничего не произошло, кроме графической подсистемы, то графика ждет, пока ядро проверит наличие действий на обработку в каждой подсистеме, вместо того, чтобы сразу сообщения от гр. подсистемы было обработано?
--> нужно выносить подсистемы в драйвера
--> нужно переписывать драйверную модель и в osloop проверять только наличие новых сообщений в буфере на обработку событий.
Osloop-то здесь при чем ?maximYCH wrote:А я расскажу, как сделать. Точнее об этом когда-то говорил diamond, я просто повторюсь.
С какой стати ЯДРО проверяет необходимость обработать в каждой подсистеме (я про 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, чем вызывать единообразную процедуру как положено.
Разобраться во всем этом добре и привести его в порядок не так уж сложно. Гораздо проще, чем городить новый огород.
Не надо все валить в одну кучу - оконный менеджер, GUI и тут еще и osloop откуда-то приперся.
Оконный интерфейс имхо более-менее компактно лежит в window.inc, а его интерактивная часть - в mouse.inc.
GUI на 70% оформлена в VESA20.inc, плюс небольшой кусочек в kernel.asm; шрифты - там где им положено.
Настоящая мешанина - в сисфункциях GUI, так уж исторически сложилось. И еще экранная карта у нас проверяется в 20 разных местах, везде с одной целью и везде по-своему. Потому что всем проще перемножить X на Y, чем вызывать единообразную процедуру как положено.
Разобраться во всем этом добре и привести его в порядок не так уж сложно. Гораздо проще, чем городить новый огород.
art_zh
Компактность эта очень условна. Структуры потоков, окон и планировщика перемешаны. Данные размазаны по всей памяти. Посмотри для примера старое определение twdw.
Компактность эта очень условна. Структуры потоков, окон и планировщика перемешаны. Данные размазаны по всей памяти. Посмотри для примера старое определение twdw.
Serge
"Чем этих отмыть - легче новых нарожать" - так, что ли?
"Чем этих отмыть - легче новых нарожать" - так, что ли?
Мне так кажется продолжение спора в таком русле будет мягко говоря неконструктивным. Колибри отличается умом и сообразительностью полной свободой самовыражения авторов. Каждый может делать свой вариант, а уже потом будет видно у кого лучше и стоит ли овчинка выделки.
Mario
При всей свободе самовыражения, существует некая генеральная линия, с которой (как потом оказывается) "все согласились".
"Все согласились, что GUI надо выносить из ядра".
- я не соглашался.
Систему (ядро+драйверы+структуры данных) надо делать компактнее, надежнее и быстрее.
Вынос GUI может привести совсем в другую сторону.
При всей свободе самовыражения, существует некая генеральная линия, с которой (как потом оказывается) "все согласились".
"Все согласились, что GUI надо выносить из ядра".
- я не соглашался.
Систему (ядро+драйверы+структуры данных) надо делать компактнее, надежнее и быстрее.
Вынос GUI может привести совсем в другую сторону.
Вынести гуй и переписать его на Си. ^__^
art_zh
Таки да. Некоторым товарищам GUI вообще не нужно. Разговор шел о том, что если вносить серьёзные изменения в диспетчер окон -"Чем этих отмыть - легче новых нарожать" - так, что ли?
- произвольное количество окон
- отрисовка элементов GUI в user-mode
- отрисовка в битмап
- использование акселерации
- тайловая архитектура
- композитный менеджер
А можно заменить ядро на Линукс и использовать X сервер как нормальные люди.
Who is online
Users browsing this forum: No registered users and 3 guests