Опять про X и Linux

Kernel-side graphics support
  • Serge
    • произвольное количество окон-- давно пора. 255 - слишком много, надо работать с хэндлами в списке, а не в массиве. Причем резать придется по живому; задача гораздо легче решается именно "внутри" ядра, чем "снаружи".
    • отрисовка элементов GUI в user-mode-- это еще зачем? юзер должен только сформировать и отправить ядру GUI-запрос (лучше - готовую очередь запросов), остальное не его дело.
    • отрисовка в битмап-- а сейчас с этим какие-то проблемы? если да - то чем модульность поможет?
    • использование акселерации-- тут без плотной работы с ресурсами ядра точно не обойтись. Только внутри, однозначно.
    • тайловая архитектура-- лучше чем пиксельная, согласен. И что? Если уж переходим на новую архитектуру - так все вместе. Иначе нужно будет разрабатывать 2 совершенно разных и несовместимых графических подсистемы.
    • композитный менеджер-- ?
    johnfound wrote:А можно заменить ядро на Линукс и использовать X сервер как нормальные люди. ;) :D
    Вот-вот, именно к этому и придём.
  • Максим плодовит на офтопы. К сожалению это все на что он плодовит. :twisted: Потому пришлось снова выдрать кусок из оригинальной темы Масштабируемые шрифты
  • art_zh
    GUI отлично рисуется в user-mode. Ещё лучше делать это в битмап. Вопрос стоит так: зачем делать в режиме ядра то, что можно сделать в приложении ? Перетаскивание и изменение размеров окна тоже реально делать в user-mode. Менять размер в самом приложении можно и сейчас. С перетаскиванием проблема - мешает обработчик в ядре. В этом случае нельзя сделать нестандартное окно с холдером справа/слева/снизу/в центре. В итоге имеем в ядре код, без которого легко обойтись -
    • изменение размеров, сворачивание в заголовок и перетаскивание окон мышкой
    • поддержка разных стилей окон, учёт размеров клиентской области
    • отрисовка окон
    • отрисовка и обработка кнопок.
  • art_zh wrote: отрисовка элементов GUI в user-mode-- это еще зачем? юзер должен только сформировать и отправить ядру GUI-запрос (лучше - готовую очередь запросов), остальное не его дело.
    Serge wrote:GUI отлично рисуется в user-mode. Ещё лучше делать это в битмап. Вопрос стоит так: зачем делать в режиме ядра то, что можно сделать в приложении ?
    Рисовать надо либо в драйвере видеокатрты либо на CPU(user mode прекрасно подходит) либо на любом другом подходящем устройстве которое в данный момент присутствует и поддержка которого тоже есть.

    Вы одно не понимаете, самое главное - надо дать програмисту Стабильный API чтобы програмисту не пришлось ничего переписовать пару десятилетий. А то прям ничего писать нехочется зная что придётся переписывать частично, полностью или забрасывать kolibri.

    Art_zh правильно предложил делать список, а какому устройству этот список скармливать зависит от того какая железка список лучше обработает. Вызываються API функции и делают новые записи в списке (потом даже, можно запросы на разные процессоры послать для отрисовки)

    А если времени нету возиться со списками запросов и оптимизацией то хотябы "заверните" системные вызовы в user-mode функции как например call dword [Rectangle] call dword [LineTo] ...
  • ilya
    я хочу реализовать GUI-буфер в динамической памяти приложения в виде односвязного списка с известной ядру точкой входа (возможно, с дополнительными перекрестными связями для перехода между отдельными элементами управления по клавише Tab).

    Serge
    Совершенно не представляю себе, как можно замутить такую штуку в 3-м круге. У ядра-то есть доступ к памяти приложения; а как будет твой менеджер отрабатывать, скажем, 50-ю функцию (чтоб ей, кстати, провалиться)?
    Через буфер обмена?
    Или будет хранить локальные фреймбуферы (битмапы) всех окон в себе?
    С перетаскиванием проблема - мешает обработчик в ядре.
    Который плотно склеен не только с перебором стека, но и с чисто ядерными службами - списком переключения задач и очередью событий. И само собой - с HID-драйверами.
  • Давайте сделаем блок-схему. Я конечно понимаю, что ни у кого нет желания, и тд и тп, но все понимают что это правильный путь. А потом, после баталий на поле схем и на поле блоков, можно переходить к воплощению.
  • Шучу, шучу. :) Я Х терпеть не могу!
  • art_zh

    Совсем не понял твою идею GUI буфера. Можно подробнее ?

    ф.50 делали в те времена, когда в ядре не было менеджера памяти и давно хотели удалить за тормоза. Так что надо хранить в ядре локальную копию или замапить буфер в пространство ядра.

    Самый простой вариант без композитного менеджера. Вся отрисовка производится программой в битмап. Функция Blit() немедленно отправляет результат на экран. Если хотим акселерацию, битмап должен создаваться системным вызовом. Оконный менеджер управляет прямоугольными областями на экране. От него требуется
    • создание и удаление окна
    • установка размеров окна
    • управление z-ордером окна и областями отсечения
    • определение событий активации и деактивации окна
    • отслеживание клавиатурного фокуса
    • отслеживание событий мыши
    • захват мыши окном
    • отрисовка курсора
    GUI реализуется в DLL и тут каждый может выбрать себе по вкусу. Кому Motif, кому KDE :)
  • Не, по вкусу GUI это хорошо, но Колибри все-таки маленькая система. И надо как-то его унифицировать, имхо.
  • Serge wrote:art_zh
    Совсем не понял твою идею GUI буфера. Можно подробнее ?
    Щас нарисую.
    Твоя схема вполне понятна. Кстати, ядерные элементы в ней-таки присутствуют :wink:
    Один только вопрос:
    Serge wrote:Оконный менеджер управляет прямоугольными областями на экране. От него требуется ... управление z-ордером окна и областями отсечения
    это очень важный момент: как думаешь реализовать экранную карту (отсечения)? Надеюсь, не на битовом поле?
  • art_zh,
    нужно выстроить генеральную линию
    и
    я не соглашался
    не соотносятся между собой. Вы самолично хотели бы выстроить генеральную линию? Тогда я процитирую другое:
    Каждый может делать свой вариант, а уже потом будет видно у кого лучше и стоит ли овчинка выделки.
    Вы можете самолично сделать в своем бранче то, что Вы задумали, также, как я сейчас пилю рабочий стол и иже с ним (когда мне примерно в том же духе сказал mike.dld о том, что если мне хочется - делай и показывай).
    Однако генеральную линию в основной ветке Вы сможете пилить только тогда, когда остальные признают, что то, что Вы сделали - лучше чем то, что имеется.
    Кстати я лучше форканусь (если, конечно, буду уже что-либо более-менее программировать под КОС), чем соглашусь участвовать в написании жесткого монолитного ядра, собираемого из исходников под каждую конкретную машину (к чем, как я понял из общения с Вами ранее Вы и стремитесь).
  • art_zh

    Текущая байтовая карта подходит для аппаратной акселерации. Так что это не самый плохой вариант. Другой вариант взять из X операции с регионами. У каждого есть свои недостатки и достоинства.

    XVilka
    Унифицированный API очень хорошо. У нас пока нет ни одной полновесной библиотеки контролов. Нужна одна такая системная.
  • Serge wrote:У нас пока нет ни одной полновесной библиотеки контролов. Нужна одна такая системная.
    Кстати, я работаю над FreshLib, которая должна иметь полную библиотеку контролов, причем полностью портируемой. Дело идет медленно, но все-таки идет. Пока есть только порты для Win32 и Линукс, но безусловно будет и версия для Колибри.
  • Сверху - как сейчас.
    Снизу - что предлагается.
    Attachments
    GUI diagram.png
    GUI diagram.png (26.24 KiB)
    Viewed 8124 times
  • Who is online

    Users browsing this forum: No registered users and 4 guests