Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пт дек 15, 2017 4:48 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 69 сообщений ]  На страницу Пред. 1 2 3 4 5 След.
Автор Сообщение
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 5:29 pm 
Не в сети

Зарегистрирован: Пт фев 18, 2011 3:13 pm
Сообщения: 201
Цитата:
Сверху - как сейчас.
Снизу - что предлагается.


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


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 5:57 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
art_zh

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


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 6:25 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
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 Вт авг 09, 2011 6:32 pm, всего редактировалось 1 раз.

Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 6:31 pm 
Не в сети

Зарегистрирован: Пт фев 18, 2011 3:13 pm
Сообщения: 201
art_zh - теперь ясно. Только терминология не очень коректна (ИМХО). А макросы, я бы заменил на вызов API функцию. Кому нравятся макросы, а кому нет. А код - это инструкции.


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 6:37 pm 
Не в сети
Kernel Developer
Аватара пользователя

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


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 6:56 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
art_zh
Элементы управления в ядре это кошмар в чистом виде. Любой чих со стороны приложения требует вызова ядра. По этой причине button единственный "ядерный" контрол в Колибри.


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 7:15 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Вт авг 25, 2009 4:45 pm
Сообщения: 788
просто разделить примитивы и контролы. Примитивы - в ядре, контролы - в юзерспейсе. По сути контролы могут быть обертками к примитивам, плюс, например стиль

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

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

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

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

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


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 9:24 pm 
Не в сети

Зарегистрирован: Вт июл 26, 2011 11:03 pm
Сообщения: 62
art_zh писал(а):
3) формируется метафайл - плоский набор тэгов и данных, не содержащий невидимых, вложенных элементов и меток..
Не вижу необходимости в копировании тэгов и параметров. Необходимость может возникнуть лишь тогда когда клиент пославший список запросов получает контроль в то время когда парсер не закончил соё работу(включая отрисовку). Это возможно?

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

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


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 9:50 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Да, там именно индексы.
Цитата:
Проверка пакета - это задача парсера. Проблем не вижу, проверяем ID пакета, кол-во координат, отсекаем координаты(x,y) как надо
И опять да. Именно так дрова и работают. Получают от программы командный буфер, парсят его, проверяют регистры на безопасность и потом отправляют gpu. Вот и вопрос: а зачем всё это делать в режиме ядра если можно рисовать в самом приложении.


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Вт авг 09, 2011 10:24 pm 
Не в сети

Зарегистрирован: Вт июл 26, 2011 11:03 pm
Сообщения: 62
Serge писал(а):
Вот и вопрос: а зачем всё это делать в режиме ядра если можно рисовать в самом приложении.
Я тоже против ядра исли всё рисуется средствами CPU, но я на это решение повлиять не смогу.
------------------------------------------------------

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

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


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Ср авг 10, 2011 5:51 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Serge писал(а):
Именно так дрова и работают. Получают от программы командный буфер, парсят его, проверяют регистры на безопасность и потом отправляют gpu. Вот и вопрос: а зачем всё это делать в режиме ядра если можно рисовать в самом приложении.

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

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

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


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Ср авг 10, 2011 6:28 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Вт авг 25, 2009 4:45 pm
Сообщения: 788
art_zh: а как насчет моей идеи - все, вплоть до примитивов включительно - в ядре, а в юзерспейсе - только виджеты и проч.? И скорость сохраняется, и расширяемость гарантирована.


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Ср авг 10, 2011 6:29 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
art_zh

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

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


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Ср авг 10, 2011 6:40 pm 
Не в сети

Зарегистрирован: Чт ноя 25, 2010 8:26 pm
Сообщения: 41
Serge писал(а):
Вот у нас в ядре точки, линии и прямоугольники есть, а треугольников и эллипсов нет. А если надо обводку в 4 пикселя? Use Cairo Luke ? Приходится рисовать в битмап.

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

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


Вернуться к началу
 Заголовок сообщения: Re: Опять про X и Linux
СообщениеДобавлено: Ср авг 10, 2011 6:45 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Вт май 08, 2007 12:44 am
Сообщения: 340
Foldl писал(а):
Так что придется запретить битмапы, тем самым заставив всех использовать только быстрые ядерные примитивы.

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

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 69 сообщений ]  На страницу Пред. 1 2 3 4 5 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB