Опять про X и Linux

Kernel-side graphics support
  • maximYCH wrote:Насколько я помню, были стремления вынести графическую подсистему из ядра, а не вбухивать в ядро ещё больше всего и вся.
    Стремления у кого-то, как мне припоминается, были. А ядерные GUI-функции и ныне там.
    И работают они очень шустро именно потому, что они ядерные.
    Может кто знает как их заставить крутиться еще быстрее, но при этом вынуть GUI-код из ядра? -- я не знаю !!
    А вот как их упорядочить, ускорить и уменьшить, оставив в ядре - это достаточно понятно.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • А я расскажу, как сделать. Точнее об этом когда-то говорил 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 сервер как нормальные люди. ;) :D
  • Who is online

    Users browsing this forum: No registered users and 6 guests