Я прекрасно помню, что
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 раз обсуждать и каждый раз все тянут в свою строну не желая идти на компромис.