Бредовые мысли об оконной подсистеме

Kernel-side graphics support
  • По моему - это совсем не бред, Колибри изначально - ось с GUI. А сделать драйвер оконной системы - вполне реально. Поддерживаю ;)
    ушёл...
  • Sorcerer
    Как программист ты можешь заниматься чем угодно, не факт что остальные тебя подержат и будут помогать, но никто ничего не запрещает.
    Выскажу свое субъективное мнение. Просьба не воспринимать как просто критику - пытаюсь обоснованно оценить.
    1) Код ядра станет проще и легче
    Сомнительно. Ничем не подтвержденное утверждение.
    2) Код gui-части системы тоже станет "изолирован" и более удобен для правок
    Никакой "изоляции" - уронить по прежнему будет легко. Насчет правок не знаю - требуется переписывание с использованием макросов и прочее, тогда может быть.
    Потерь в скорости работы оконной подсистемы быть не должно, потому что работает все в ring 0
    Тут согласен -как минимум заметно медленнее не станет.
    4) Если не исключать некоторое время (допустим, пару релизов) старый код gui из ядра, то никаких проблем с совместимостью не предвидится - исправленные программы будут работать через "драйвер" оконной системы, неисправленные - обращаться к ядру (а ядро вполне может редиректить их к "драйверу")
    Неоптимальный подход - если уж переделывать, то переделывать, полумеры вредны.
    Но сейчас же никто не мешает программам писать напрямую хоть в kernel.mnt?
    В системе нет разделения прав, со всеми вытекающими. Ядро это обычный файл.

    С точки зрения эффективности нужно проектирование и планирование. Иначе может получиться очередная перетряска ядра добавляющаяя еще костылей.
  • Согласен по всем пунктам.

    Изолирован в смысле локализован?
  • С пунктами - согласен, с базовой концепцией - нет.
    Переделка ядра нужна только если она делает систему быстрее, компактнее и надёжнее.
    Sorcerer wrote:Идея такая. Драйвер для Колибри - по сути, библиотека с немного другим API, выполняющаяся в ring 0 и имеющая только одну копию в памяти для всех запущенных программ, так?
    Такая "ядерная" библиотека уже существует и более-менее удовлетворительно работает.
    Вынесение кода из ядра в драйвер не сделает систему ни компактнее, ни производительнее.
    Всё равно каждый вызов GUI-драйвера будет требовать входа в ring0.

    Альтернатива 1 (наихудшая): перенести драйвер в ring3-DLL.
    -- Будет работать гораздо быстрее, но крайне ненадёжно.

    Альтернатива 2 (наилучшая): сделать обработку GUI-вызовов асинхронной.
    -- Приложение не должно стучаться в ring0 по каждому ерундовому поводу. Вместо этого имеет смысл реализовать общесистемный буфер GUI-запросов, который будет периодически обрабатываться драйвером-модулем графической подсистемы.
    Все буферизованные запросы обрабатывать одним системным вызовом
    - с возможностью дальнейшей оптимизации отрисовки перекрытых окон, работы с оконным стеком, панелью, стрелкой мыши и курсором
    - и аппаратной акселерации части GUI-запросов на GPU.

    Второй подход позволит значительно увеличить производительность графической подсистемы при сохранении существующего уровня надежности.
    Размер системы (ядро+графический модуль)
    - для неоптимизированной буферизации GUI-запросов заметно не изменится;
    - многопроходная оптимизация раздует код, но ещё больше увеличит скорость;
    - GPU-акселератор позволит значительно сократить системный код при одновременном увеличении производительности.
    Важно: графический модуль можно будет легко менять/апгрейдить/переключать без переделки GUI-кода приложений.
  • Who is online

    Users browsing this forum: No registered users and 3 guests