Обсуждение графической подсистемы

Kernel-side graphics support
  • Есть ещё одна проблема: медленный IPC.
    Ведь что-бы вывести строку текста, придётся послать сообщение X-серверу, а строк может оказаться не один десяток. X-сервер, в свою очередь, отреагирует лишь когда до него очередь дойдёт.
  • Раз почти никому это не надо, то сделаю так, как считаю нужным.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • andrew_programmer
    Если не секрет, то как именно ты считаешь нужным? Очень интересно.
  • Если как по мне, то все функции рисования и работы с окнами, что сейчас есть в ядре, только мешают нормальной работе с графикой и окнами. В результате получается куча костылей и в коде ядра разобраться значительно сложнее.
    Я считаю, что в ядре должны работать только динамически подгружаемые драйверы. Но не одной программе нельзя будет обращаться к этим драйверам напрямую. Для создания окон и рисования в них, нужно обращаться к специальному процессу, который будет общаться с драйверами работающими в ядре и выполнять ту же роль, что и X-server в Unix системах. Да, сейчас IPC медленно работает, но ни что не мешает переделать его как надо. Исходники открыты. Это вопрос только времени выполнения работы.
    Поначалу надо реализовать X-server используя те возможности, что сейчас есть в Колибри. Провести эксперименты. Так как код будет писаться на C/C++, то адаптировать его под исправленную систему будет не сложно.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • спасибо.
    сложно, но ИМХО правильно...
    а насколько прикладному программисту будет сложнее писать программы? и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?
  • а насколько прикладному программисту будет сложнее писать программы?
    Вот когда сделаю, тогда и обсудим. :)
    и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?
    Так оконная подситема - это логический код, а драйверы в KolibriOS написаны на ассемблере(за исключением драйвера ATI).
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Я давно говорил, что графику нужно максимально вынести из ядра. Набор системных функций, начинающийся с функции рисования окна, выглядит как-то нелепо.

    Вообще отдельный процесс - это явно графическая оболочка. Другое дело, какие функции на нее возложить и как с ней взаимодействовать. Непосредственно выводом на экран может управлять GUI-сервер, работающий в пространстве ядра (это единственное, что его связывает с ядром). Оболочке можно передавать лишь короткие сообщения, связанные с атрибутами/состоянием окна к примеру на таскбаре или в трее, причем не через имеющиеся средства IPC, а через тот же GUI-сервер.
  • andrew_programmer wrote:Если как по мне, то все функции рисования и работы с окнами, что сейчас есть в ядре, только мешают нормальной работе с графикой и окнами. В результате получается куча костылей и в коде ядра разобраться значительно сложнее.
    "Если это глупо, но работает, значит, это не глупо." (c) из законов Мерфи
    В данный момент графика и окна вполне себе работают. На основании каких фактов делается вывод, что работа ненормальная?
    Примеры костылей, кстати, в студию.
    Очевидно, что сами по себе функции рисования и работы с окнами в том или ином виде в системе останутся. Следовательно, разобраться в них будет заведомо не проще, чем сейчас. А поскольку добавятся обёртывающие слои, в которых тоже нужно будет разбираться, то предлагаемые изменения ведут к усложнению понимания, а не наоборот.
    andrew_programmer wrote:Я считаю, что в ядре должны работать только динамически подгружаемые драйверы. Но ни одной программе нельзя будет обращаться к этим драйверам напрямую. Для создания окон и рисования в них, нужно обращаться к специальному процессу, который будет общаться с драйверами работающими в ядре и выполнять ту же роль, что и X-server в Unix системах. Да, сейчас IPC медленно работает, но ни что не мешает переделать его как надо. Исходники открыты. Это вопрос только времени выполнения работы.
    Специальный процесс - это независимо ни от чего минус к скорости, причём довольно заметный. Приложение хочет нарисовать окно и вместо того, чтобы одним системным вызовом попасть в код создания окна, подаёт сигнал серверу. Который - вот незадача! - постоянно занят отрисовкой всяких линий, потому что где-то на заднем фоне пользователь поставил что-то крутиться для красоты. Независимо от реализации IPC будут тормоза.
    Лично я против любых ненужных дополнительных слоёв. Необходимость X-сервера явно как минимум сомнительна.
    andrew_programmer wrote:и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?
    Лично я - отрицательно.
    Phantom84 wrote:Я давно говорил, что графику нужно максимально вынести из ядра.
    С целью?
    Ушёл к умным, знающим и культурным людям.
  • Я прекрасно помню, что diamond противник вынесения какой-либо графики из ядра.
    А ещё есть сторонники идеи,"Нечего засорять ядро всяким гов**м". Попробуйте найти компромисное решение, удовлетворяющее и первым, и вторым....
    Теперь к делу.
    "Если это глупо, но работает, значит, это не глупо." (c) из законов Мерфи
    Я не утверждал, что это глупо.
    В данный момент графика и окна вполне себе работают. На основании каких фактов делается вывод, что работа ненормальная?
    Вот в Windows для организации интерфейса есть окна следующих типов: главное окно, дочернее окно, всплывающее окно. Функции рисования окон аппаратно ускорены. Также в windows есть библиотека GDI в которой есть все необходимые функции рисования. Причём они аппаратно ускоренные и нет никакого намёка на драйверы для различных устройств. Программист просто пользуется библиотекой не парясь ни о каких драйверах. Теперь подумаем о возможности реализации всего этого в KolibriOS.
    1)Главное окно есть? Да. Дочерние окна есть? Нет. Можно только попытаться эмулировать это программно, причём в некоторых случаях с потерей производительности и с добавкой дополнительного кода. Всплывающие окна есть? Нет. Окон, которые всегда на самом верху - нет. И на данный момент эмулировать их просто невозможно! Я уже не говорю об аппаратной отрисовке окон.
    2)Аппаратное ускорение возможно задействовать обращением к операционной системе через прерывания без помощи сторонних библиотек? Нет.
    А если я захочу задействовать аппаратное ускорение 3D, что тогда делать? Mesa, между прочим, взаимодействует с X-server-ом для аппаратной отрисовки внутри окон.
    Примеры костылей, кстати, в студию.
    Примеры давно уже у всех на слуху. То и дело люди жалуются на артефакты "след окна" возникающие при пересечении иконок и окон обычных приложений. Отрисовка курсора: скрываем курсор, рисуем, отображаем. Это ужас. Текст и числа отрисовывает операционная система. Кнопки отрисовывает операционная система. А если я захочу 10000 кнопок то все их должна перебирать операционная система. Как тогда насчёт времени отклика и скорости работы OS? Сколько раз повторялись глюки с незакрытием окна, из-за пересечения областей кнопок и кнопки закрытия окна. Вывод битмапа только 24 бита. Если с палитрой, то отдельная ситемная подфункция. Неужели по всякому поводу будем заводить подфункции системных функций?
    Смотрим внимательно на код ядра. То здесь, то там вылезает кусок кода касающийся GUI. Причём все время надо проверять к какому процессу относиться, смотреть параметры окон, рабочей области. Буфер этот статический на 255 элементов. А если захочется больше потоков, значит заново перекраивать код и учитывать специфику разбросанного кода GUI в ядре? Статический код графики и GUI приводит к путанице и бардаку в ядре усложняя понимание и соответственно модернизацию этого кода.
    Вообще, задача операционной системы распределять системные ресурсы и разграничивать их между процессами. А не рисованием заниматься.
    Очевидно, что сами по себе функции рисования и работы с окнами в том или ином виде в системе останутся. Следовательно, разобраться в них будет заведомо не проще, чем сейчас. А поскольку добавятся обёртывающие слои, в которых тоже нужно будет разбираться, то предлагаемые изменения ведут к усложнению понимания, а не наоборот.
    Если всё делать правильно, то программист будет просто наслаждаться удобством пользования библиотекой. Как это сейчас с InfinitySound. Не нужно париться с драйверами и их устройством - есть промежуточный абстрактный слой.
    Специальный процесс - это независимо ни от чего минус к скорости, причём довольно заметный. Приложение хочет нарисовать окно и вместо того, чтобы одним системным вызовом попасть в код создания окна, подаёт сигнал серверу. Который - вот незадача! - постоянно занят отрисовкой всяких линий, потому что где-то на заднем фоне пользователь поставил что-то крутиться для красоты. Независимо от реализации IPC будут тормоза.
    Лично я против любых ненужных дополнительных слоёв. Необходимость X-сервера явно как минимум сомнительна.
    :) :) :)
    diamond, ты не обижайся на меня, но ты когда-нибудь пользовался по нормальному Linux-ом? Запускал в нём 3D эффекты Compiz? Сравнивал FPS-ы скажем Quake в Linux с Quake в Windows?
    Я сравнивал. FPS-ы почти одинаковые. А знаешь почему? Потому что драйверы: видео, мыши, клавиатуры работают в ядре. А X-server выполняет роль полицейского распределяющего эти ресурсы между окнами приложений, посылающих запросы. Тоже самое я предлагаю и для KolibriOS. Драйверы в ядре, "полицейский" в user mode.

    Теперь более конкретно о задаче. Решение задачи - это поиск оптимального решения. Когда искомое решение является функцией одного параметра, то тут всё ясно с оптимизацией. Когда ищется оптимальное решение сразу по нескольким параметрам, то тут всё сложнее, тем более, что у разных людей набор этих параметров различается.
    Теперь о параметрах.
    Что мы хотим от KolibriOS?
    1) Максимальная скорость требует размещения в ядре драйверов. Безопасность требует размещения драйверов в пользовательском пространстве.
    2) Удобство разработки и модернизации требует модульности операционной системы. Тогда в ядре должно быть меньше кода. Драйверы по возможности на C, хотя тут есть проблема доверия компиляторам ЯВУ. Тогда больше шансов добавить поддержку 64 битности и SMP. Всё на ассемблере, тогда быстрее(не известно на сколько процентов) и стабильние (в смысле ошибок компилятора), но портирумость и простота модернизации под новые возможности почти нулевая.

    Пытаясь найти компромисс пришёл к следующему решению.
    Драйверы в ядре. Конёк KolibriOS - это скорость. Менеджер окон и отрисовки в пользовательском процессе, потому что:
    a)Легкость модернизации кода. Несущественно ограничение на число процессов, которые может обеспечить OS. Любое приложение автоматически будет использовать аппаратные возможности драйверов не зная особенности их работы. Можно написать любой декоратор окон и задействовать различные эффекты окон.
    б)Нет лишнего кода в ядре, вносящего путаницу и усложняющего его. Нет привязки к особенностям драйверов видео.
    с)Меньше статических драйверов в ядре. Больше шансов добавить SMP. А вот шансов добавить 64 бита без полного переписывания кода - нет.
    d)Оконная подсистема на C, потому что код логический, а не вычислительный. И дабы увеличить скорость разработки и портируемость кода, пишется на C. Может код ещё пригодится для какого-нибудь микро ядра. :)

    До тех пор пока мы ОКОНЧАТЕЛЬНО не решим чего мы ВСЕ хотим от KolibriOS так и будут споры,"Какой должна быть KolibriOS?". Надоело по 100 раз обсуждать и каждый раз все тянут в свою строну не желая идти на компромис.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • andrew_programmer, ты мыслишь в правильную сторону, но зачем оставлять драйверы в ядре?
    З.Ы. SMP без PnP и ACPI - пустая трата времени. Когда дойдет очередь до PnP или ACPI придется опять переписывать.
  • Драйверы не в ядре - это уже микро ядро. Тема микро ядра обсуждается у нас в новостях. :)
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Кто сказал? Я про физическое разделение драйверов от ядра, а не о переводе их из ring 0 куда либо. Если драйвера выполняются в нулевом кольце и в одном адресном пространстве с ядром, это ещё монолитное ядро. Или я что-то путаю? :)
  • Если ты имел ввиду выделение кода драйверов в отдельные DLL, то я тоже за это. Устройств много, а ядро одно. Нечего его кодом драйверов засорять.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Угу, я про это.
  • Who is online

    Users browsing this forum: No registered users and 8 guests