Вопрос по текущему ядру KolibriOS. Оконной подсистеме, необходимо работать с драйверами: видео, мыши, клавиатуры. В Linux этим занимается X-sercer(в пространстве приложений) в Windows это всё в ядре. В общем нужно решить вопрос, как быть.
1)Графику в user mode отдельным процессом типа X-server в Linux.
2) Каждая программа будет использовать специальную библиотеку уровня ядра для работы с различными драйверами и с окнами. Типа как сейчас звук через Infinity.
3)Оставить всё как есть и пусть каждая программа сама мучается с окнами и драйверами или вообще их не использует.
Без решения этой проблемы, с окошками в текущей KolibriOS ничего нормального не сделать.
Обсуждение графической подсистемы
-
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Есть ещё одна проблема: медленный IPC.
Ведь что-бы вывести строку текста, придётся послать сообщение X-серверу, а строк может оказаться не один десяток. X-сервер, в свою очередь, отреагирует лишь когда до него очередь дойдёт.
Ведь что-бы вывести строку текста, придётся послать сообщение X-серверу, а строк может оказаться не один десяток. X-сервер, в свою очередь, отреагирует лишь когда до него очередь дойдёт.
Раз почти никому это не надо, то сделаю так, как считаю нужным.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
andrew_programmer
Если не секрет, то как именно ты считаешь нужным? Очень интересно.
Если не секрет, то как именно ты считаешь нужным? Очень интересно.
Если как по мне, то все функции рисования и работы с окнами, что сейчас есть в ядре, только мешают нормальной работе с графикой и окнами. В результате получается куча костылей и в коде ядра разобраться значительно сложнее.
Я считаю, что в ядре должны работать только динамически подгружаемые драйверы. Но не одной программе нельзя будет обращаться к этим драйверам напрямую. Для создания окон и рисования в них, нужно обращаться к специальному процессу, который будет общаться с драйверами работающими в ядре и выполнять ту же роль, что и X-server в Unix системах. Да, сейчас IPC медленно работает, но ни что не мешает переделать его как надо. Исходники открыты. Это вопрос только времени выполнения работы.
Поначалу надо реализовать X-server используя те возможности, что сейчас есть в Колибри. Провести эксперименты. Так как код будет писаться на C/C++, то адаптировать его под исправленную систему будет не сложно.
Я считаю, что в ядре должны работать только динамически подгружаемые драйверы. Но не одной программе нельзя будет обращаться к этим драйверам напрямую. Для создания окон и рисования в них, нужно обращаться к специальному процессу, который будет общаться с драйверами работающими в ядре и выполнять ту же роль, что и X-server в Unix системах. Да, сейчас IPC медленно работает, но ни что не мешает переделать его как надо. Исходники открыты. Это вопрос только времени выполнения работы.
Поначалу надо реализовать X-server используя те возможности, что сейчас есть в Колибри. Провести эксперименты. Так как код будет писаться на C/C++, то адаптировать его под исправленную систему будет не сложно.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
спасибо.
сложно, но ИМХО правильно...
а насколько прикладному программисту будет сложнее писать программы? и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?
сложно, но ИМХО правильно...
а насколько прикладному программисту будет сложнее писать программы? и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?
Вот когда сделаю, тогда и обсудим.а насколько прикладному программисту будет сложнее писать программы?
Так оконная подситема - это логический код, а драйверы в KolibriOS написаны на ассемблере(за исключением драйвера ATI).и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Я давно говорил, что графику нужно максимально вынести из ядра. Набор системных функций, начинающийся с функции рисования окна, выглядит как-то нелепо.
Вообще отдельный процесс - это явно графическая оболочка. Другое дело, какие функции на нее возложить и как с ней взаимодействовать. Непосредственно выводом на экран может управлять GUI-сервер, работающий в пространстве ядра (это единственное, что его связывает с ядром). Оболочке можно передавать лишь короткие сообщения, связанные с атрибутами/состоянием окна к примеру на таскбаре или в трее, причем не через имеющиеся средства IPC, а через тот же GUI-сервер.
Вообще отдельный процесс - это явно графическая оболочка. Другое дело, какие функции на нее возложить и как с ней взаимодействовать. Непосредственно выводом на экран может управлять GUI-сервер, работающий в пространстве ядра (это единственное, что его связывает с ядром). Оболочке можно передавать лишь короткие сообщения, связанные с атрибутами/состоянием окна к примеру на таскбаре или в трее, причем не через имеющиеся средства IPC, а через тот же GUI-сервер.
"Если это глупо, но работает, значит, это не глупо." (c) из законов Мерфиandrew_programmer wrote:Если как по мне, то все функции рисования и работы с окнами, что сейчас есть в ядре, только мешают нормальной работе с графикой и окнами. В результате получается куча костылей и в коде ядра разобраться значительно сложнее.
В данный момент графика и окна вполне себе работают. На основании каких фактов делается вывод, что работа ненормальная?
Примеры костылей, кстати, в студию.
Очевидно, что сами по себе функции рисования и работы с окнами в том или ином виде в системе останутся. Следовательно, разобраться в них будет заведомо не проще, чем сейчас. А поскольку добавятся обёртывающие слои, в которых тоже нужно будет разбираться, то предлагаемые изменения ведут к усложнению понимания, а не наоборот.
Специальный процесс - это независимо ни от чего минус к скорости, причём довольно заметный. Приложение хочет нарисовать окно и вместо того, чтобы одним системным вызовом попасть в код создания окна, подаёт сигнал серверу. Который - вот незадача! - постоянно занят отрисовкой всяких линий, потому что где-то на заднем фоне пользователь поставил что-то крутиться для красоты. Независимо от реализации IPC будут тормоза.andrew_programmer wrote:Я считаю, что в ядре должны работать только динамически подгружаемые драйверы. Но ни одной программе нельзя будет обращаться к этим драйверам напрямую. Для создания окон и рисования в них, нужно обращаться к специальному процессу, который будет общаться с драйверами работающими в ядре и выполнять ту же роль, что и X-server в Unix системах. Да, сейчас IPC медленно работает, но ни что не мешает переделать его как надо. Исходники открыты. Это вопрос только времени выполнения работы.
Лично я против любых ненужных дополнительных слоёв. Необходимость X-сервера явно как минимум сомнительна.
Лично я - отрицательно.andrew_programmer wrote:и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?
С целью?Phantom84 wrote:Я давно говорил, что графику нужно максимально вынести из ядра.
Ушёл к умным, знающим и культурным людям.
Я прекрасно помню, что diamond противник вынесения какой-либо графики из ядра.
А ещё есть сторонники идеи,"Нечего засорять ядро всяким гов**м". Попробуйте найти компромисное решение, удовлетворяющее и первым, и вторым....
Теперь к делу.
1)Главное окно есть? Да. Дочерние окна есть? Нет. Можно только попытаться эмулировать это программно, причём в некоторых случаях с потерей производительности и с добавкой дополнительного кода. Всплывающие окна есть? Нет. Окон, которые всегда на самом верху - нет. И на данный момент эмулировать их просто невозможно! Я уже не говорю об аппаратной отрисовке окон.
2)Аппаратное ускорение возможно задействовать обращением к операционной системе через прерывания без помощи сторонних библиотек? Нет.
А если я захочу задействовать аппаратное ускорение 3D, что тогда делать? Mesa, между прочим, взаимодействует с X-server-ом для аппаратной отрисовки внутри окон.
Смотрим внимательно на код ядра. То здесь, то там вылезает кусок кода касающийся GUI. Причём все время надо проверять к какому процессу относиться, смотреть параметры окон, рабочей области. Буфер этот статический на 255 элементов. А если захочется больше потоков, значит заново перекраивать код и учитывать специфику разбросанного кода GUI в ядре? Статический код графики и GUI приводит к путанице и бардаку в ядре усложняя понимание и соответственно модернизацию этого кода.
Вообще, задача операционной системы распределять системные ресурсы и разграничивать их между процессами. А не рисованием заниматься.
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 раз обсуждать и каждый раз все тянут в свою строну не желая идти на компромис.
А ещё есть сторонники идеи,"Нечего засорять ядро всяким гов**м". Попробуйте найти компромисное решение, удовлетворяющее и первым, и вторым....
Теперь к делу.
Я не утверждал, что это глупо."Если это глупо, но работает, значит, это не глупо." (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!
Kolibri is best operation system in the world!
andrew_programmer, ты мыслишь в правильную сторону, но зачем оставлять драйверы в ядре?
З.Ы. SMP без PnP и ACPI - пустая трата времени. Когда дойдет очередь до PnP или ACPI придется опять переписывать.
З.Ы. SMP без PnP и ACPI - пустая трата времени. Когда дойдет очередь до PnP или ACPI придется опять переписывать.
Драйверы не в ядре - это уже микро ядро. Тема микро ядра обсуждается у нас в новостях.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Кто сказал? Я про физическое разделение драйверов от ядра, а не о переводе их из ring 0 куда либо. Если драйвера выполняются в нулевом кольце и в одном адресном пространстве с ядром, это ещё монолитное ядро. Или я что-то путаю?
Если ты имел ввиду выделение кода драйверов в отдельные DLL, то я тоже за это. Устройств много, а ядро одно. Нечего его кодом драйверов засорять.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Угу, я про это.
Who is online
Users browsing this forum: No registered users and 3 guests