Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Dec 15, 2019 11:03 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 69 posts ]  Go to page 1 2 3 4 5 Next
Author Message
PostPosted: Sun Aug 07, 2011 5:57 pm 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
Quote:
[ядерный]

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


Top
   
PostPosted: Sun Aug 07, 2011 9:12 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1359
maximYCH wrote:
Насколько я помню, были стремления вынести графическую подсистему из ядра, а не вбухивать в ядро ещё больше всего и вся.

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

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
PostPosted: Mon Aug 08, 2011 9:49 am 
Offline

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


Top
   
PostPosted: Mon Aug 08, 2011 12:42 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1359
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 из ядра" ?!.


Top
   
PostPosted: Mon Aug 08, 2011 1:28 pm 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
Quote:
Ты его хочешь подключить к обработке очередей GUI-запросов.
И это будет "вынос GUI из ядра" ?!.

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


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


Top
   
PostPosted: Mon Aug 08, 2011 1:57 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
По сути maximYCH прав. Разговор давно шёл о том чтобы вынести код оконной системы в отдельный модуль. А то сейчас там слишком всё перемешано.


Top
   
PostPosted: Mon Aug 08, 2011 2:22 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1359
Serge
Не надо все валить в одну кучу - оконный менеджер, GUI и тут еще и osloop откуда-то приперся.

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

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

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


Top
   
PostPosted: Mon Aug 08, 2011 2:55 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh
Компактность эта очень условна. Структуры потоков, окон и планировщика перемешаны. Данные размазаны по всей памяти. Посмотри для примера старое определение twdw.


Top
   
PostPosted: Mon Aug 08, 2011 3:17 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1359
Serge
"Чем этих отмыть - легче новых нарожать" - так, что ли?


Top
   
PostPosted: Mon Aug 08, 2011 3:29 pm 
Мне так кажется продолжение спора в таком русле будет мягко говоря неконструктивным. Колибри отличается умом и сообразительностью полной свободой самовыражения авторов. Каждый может делать свой вариант, а уже потом будет видно у кого лучше и стоит ли овчинка выделки.


Top
   
PostPosted: Mon Aug 08, 2011 3:50 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1359
Mario
При всей свободе самовыражения, существует некая генеральная линия, с которой (как потом оказывается) "все согласились".

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

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


Top
   
PostPosted: Mon Aug 08, 2011 4:45 pm 
Offline
User avatar

Joined: Tue Jan 24, 2006 8:50 am
Posts: 249
Вынести гуй и переписать его на Си. ^__^


Top
   
PostPosted: Mon Aug 08, 2011 4:48 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh
Quote:
"Чем этих отмыть - легче новых нарожать" - так, что ли?
Таки да. Некоторым товарищам GUI вообще не нужно. Разговор шел о том, что если вносить серьёзные изменения в диспетчер окон -
  • произвольное количество окон
  • отрисовка элементов GUI в user-mode
  • отрисовка в битмап
  • использование акселерации
  • тайловая архитектура
  • композитный менеджер
то желательно сделать всё это в виде отдельного модуля. Это пойдёт на пользу как ядру так и менеджеру. Делать это (отдельный модуль) просто ради "шоб було" не зачем.


Top
   
PostPosted: Mon Aug 08, 2011 5:05 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
А можно заменить ядро на Линукс и использовать X сервер как нормальные люди. ;) :D


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 69 posts ]  Go to page 1 2 3 4 5 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited