Board.KolibriOS.org

Наверх - более менее понятно. А снизу совершенно неясно. Как будет выглядеть код потребителя (то что на верхней диаграме "....int 40h"). Что это "heap"? Что это "tag"? A "The Metafile"?
А что делает "The Parser"?

art_zh

У нас с тобой путаница в терминологии. В моём понимании GUI это элементы управления - button radiobutton scrollbox listbox updown progress bar status bar и т.д. А ты нарисовал список запросов на отрисовку к графической подсистеме. Такую вещь лучше делать с помощью кольцевого командного буфера по аналогии с командным процессором GPU. Требуется три указателя - записи writeptr, чтения readptr и на сам буфер. Если writeptr==readptr буфер пуст. Клиент записывает командный пакет в буфер и обновляет writeptr. Сервис читает данные из буфера и обновляет readptr пока writeptr!=readptr. Всё работает замечательно, пока криворукий программист не накосячит с пакетом.

johnfound
Пользовательский код будет выглядеть примерно так:

add_gui win_init, Xleft, Ytop, Xright, Ybottom, skin, boxcolor, win_title
add_gui tag_moveto, X0, Y0 
add_gui tag_setcolor, 0x0203010
add_gui tag_lineto, X1, Y1
add_qui tag_lineto, X2, Y2
...
add_gui tag_moveto, X3, Y3
add_qui tag_text, asciiz_string1 
...

Как можно догадаться, win_init и add_gui - макросы, вставляющие в GUI-список новый элемент с соответствующими данных тэгами и полями данных.
В Круге 0 по запросу оконного менеджера (при необходимости перерисовки окна или всего экрана)
1) происходит чтение GUI-списка задачи,
2) тэги проверяются на корректность, а координаты - на попадание в видимую зону экрана,
3) формируется метафайл - плоский набор тэгов и данных, не содержащий невидимых, вложенных элементов и меток.
4) парсер отрисовывает в один проход все видимые элементы всех окон.

идея сырая, принимаются любые конструктивные предложения.

Serge
Я имею в виду полную ревизию GUI-функций системы, включая элементы управления.
С линиями просто (с них можно начинать уже сейчас), с окнами и вложенными тэгами - сложнее, с кнопками пока много неясного.

art_zh - теперь ясно. Только терминология не очень коректна (ИМХО). А макросы, я бы заменил на вызов API функцию. Кому нравятся макросы, а кому нет. А код - это инструкции.

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

art_zh
Элементы управления в ядре это кошмар в чистом виде. Любой чих со стороны приложения требует вызова ядра. По этой причине button единственный "ядерный" контрол в Колибри.

просто разделить примитивы и контролы. Примитивы - в ядре, контролы - в юзерспейсе. По сути контролы могут быть обертками к примитивам, плюс, например стиль

А по-поводу внутренней структуры графики - предлагаю посмотреть внутренности EFL (elnlighment toolkit) - и использовать схожие принципы архитектуры (за вычетом Х-сервера, конечно)

http://trac.enlightenment.org/e/wiki/EFLOverview
а вот тут - подробная, так сказать, картинка. http://docs.enlightenment.org/books/efl ... icture.pdf

Почему именно EFL? Потому что у него внутри все очень красиво. Очень академический проект.

Например взять в ядро все, что ниже, включительно Evas - тогда получиться реализация Canvas в ядре.

По поводу отрисовки текста - надо его так спроектировать, чтобы в будущем можно было вставить как векторные шрифты, так и растровые, с автохайтингом.

Не вижу необходимости в копировании тэгов и параметров. Необходимость может возникнуть лишь тогда когда клиент пославший список запросов получает контроль в то время когда парсер не закончил соё работу(включая отрисовку). Это возможно?

Думаю что такую ситуацую можно разрулить в помощью кольцевого буфера предложеным Serge.
Нужен указатель только на сам буфер, остальные будут смещение(или индексы) относительно начала буфера. Например если макс размер буфера 64KB то индексы по 2 байта. Чтобы когда кто-нибуть напортачит с индексами, не произошло обращения за пределы буфера. Единственная оставшая проблема тут - парсер не нарисует правильные примитивы так-как индексы неправильные. Но это проблема клиента.

Проверка пакета - это задача парсера. Проблем не вижу, проверяем ID пакета, кол-во координат, отсекаем координаты(x,y) как надо

Да, там именно индексы.И опять да. Именно так дрова и работают. Получают от программы командный буфер, парсят его, проверяют регистры на безопасность и потом отправляют gpu. Вот и вопрос: а зачем всё это делать в режиме ядра если можно рисовать в самом приложении.

Я тоже против ядра исли всё рисуется средствами CPU, но я на это решение повлиять не смогу.
------------------------------------------------------

А теперь представим(сложно но попытайтесть) что NVIDIA решила написать дрова для Kolibri. Но она только готова взять ответственность за рисование кривой T-Spline(есть такое) и закраски прямоугольника. Ей удобнее обрабатывать другой формат списка примитивов и в дополнение только T-Spline и прямоугольник. При использовании функций (а не макросов) дочтаточно лишь загрузит библиотеку nvidia и пропатчить адреса (at runtime) программы. При использовании макросов нужно просить програмиста скомпилировать вторую версию програмы.

Ещё представте. Новая версия драйверов AMD рисует линии и кривые немного подругому. Врезультате все програмы рисуют козябры а не текст(особено мелкий). При использование функций, рядовой домохозяйке, надо лишь поставить галочку в настройках - "для текста не исрользовать видеокарту а использовать CPU" для возвращения текста в норму в то время как остальные линии и все фигуры продолжают использовать быструю видеокарту для отрисовки.

Дрова будут работать с векторной графикой?
Даже с блиттером не все так однозаначно, как хотелось бы: приложение рисует битмап, а GPU должен его загонять на экран. Но ведь обрезкой невидимых частей пока что занят CPU, так? Если мой битмап 800х600, то это уже полмиллиона пикселей. Что, будем их все проверять по битовому полю, а потом резать на куски?
Хотя бы для полнооконных битмап-приложений вроде FPLAY, KIV или KFAR - ожидается ли хоть какое-нибудь ускорение по сравнению с нынешней ядерной графикой?
Если да - то какое?
Если нет - то зачем?

А с простейшей векторной и пиксельной графикой - вообще караул: значит, я должен сначала подгрузить к своей 500-байтовой программке библиотеку в стопятьсоткилобайт, заказать мегабайтный буфер для оконного битмапа, начертить в этом буфере 30 букв и 20 цифирок - а потом отправить запрос твоему мегадрайверу, чтобы он заблиттил мой статический текст на экран??

Да лучше я буду напрямую через фреймбуфер рисовать, чем такое счастье.
Если что-то выносить из ядра - то для пользы дела, а не во вред.

art_zh: а как насчет моей идеи - все, вплоть до примитивов включительно - в ядре, а в юзерспейсе - только виджеты и проч.? И скорость сохраняется, и расширяемость гарантирована.

art_zh

А что 100500 килобайт в ядре лучше 100500 килобайт в usermode ? И как определить что должно быть в этих стапятистах килобайтах, а что нет. Вот у нас в ядре точки, линии и прямоугольники есть, а треугольников и эллипсов нет. А если надо обводку в 4 пикселя? Use Cairo Luke ? Приходится рисовать в битмап.

GPU может делать отсечение по карте окон. Шейдер я уже приводил. Для Fplay при выводе через блиттер загрузка процессора снижается в 1.5-1.8 раза. И какая разница рисовать во фреймбуфер или в битмап если на экран всё выводится одной функцией ? Если будет композитный менеджер то ты вообще не сможешь в видеопамять рисовать.

Кстати да! Иксы поддерживают шрифты на стороне сервера, но библиотеки гоняют битмапы туда-сюда даже через сеть. Выходит, что поддерживается никому не нужный функционал.

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

Ура-а-а, наконец-то хоть у кого-то интерфейс станет набором векторов, а не пятном на экране.

_________________
Разработчик языка программирования Кантор