Разработка GUI фреймворка с аппаратным ускорением на Си

например у меня на пропиретарных драйверах валится обратно на software, а на открытых вот так

может проще пофиксить Qt, чем писать с нуля свой велосипед?

Это не изменит того, что в Qt аппаратное ускорение по-умолчанию не будет использоваться. Да и в Си на Qt не попрограммировать вообще-то. Всё равно останется проблема, под Си нет аппаратно ускоренных хороших GUI фреймворков.

Без возможности software rendering? Не нужно же, в ssh -X работать нормально не сможет.

Я вообще надеюсь, что Xorg скоро умрёт, но глядя на wayland который в конвульсиях кушает 78% CPU, теряю надежду.

Mesa разве не обеспечивает software rendering для OpenGL 3.3?

Я вообще надеюсь, что Xorg скоро умрёт

Я бы не стал желать смерти единственному адекватному способу рисовать графику на линуксе.

GTK+ же.

Там обещали аппаратное ускорение и OpenGL для прорисовки виджетов. Когда-то.

Кстати, в SLED когда-то была такая штука: http://ru.wikipedia.org/wiki/Glitz, вернее, GTK её использовало через Cairo-Glitz. До сих пор помню, как приятно было работать в GNOME, всё так быстро, плавно. Не то, что в федоре тех же времён.

В общем, если хочешь действительно чего-то эдакого, попробуй воскресить Glitz в современных реалиях и обновить для неё Cairo. Авось что выйдет.

Да, GTK мне многим нравится, но слишком он уж объёмный и тяжёлый. В cairo есть OpenGL бекэнд, но работает он криво(да и пересобирать cairo приходится чтобы его использовать). В исходниках cairo мне никогда не разобраться, там такая мишура, ужас просто имхо.

Да и хотелось бы кросплатформенность(если построить GUI фреймворк на OpenGL то это будет раз плюнуть), а про GTK3 на windows я вообще молчу, миссия не выполнима, да и кто будет ставить эту тонну библиотек в здравом уме?

У Glib и GTK+ очень простой и внятный код, на самом деле. Учитывая это, объём вовсе не страшен.

на Си

Нужно

OpenGL 3.3

Не нужно

Чем это вам OpenGL 3.3 не приглянулся? Что же тогда использовать предлагаете?

Тем, что на говнодевайсах оно не будет работать

OpenGL ES очевидно же.

//выдери гуи ищ блендера, он там аппаратно ускоренный и вообще ня

и как раз на си, да

Почти все современные видеокарты поддерживают OpenGL 3.3, и, вроде Mesa тоже поддерживает. Про шиндовс не знаю, но скорее всего тоже поддерживает(играют же они в игры как-то).

Почти все современные видеокарты поддерживают OpenGL 3.3

Но не у всех есть «почти все современные видеокарты», по разным причинам.

Для них есть Mesa которая предоставляет software rendering. Да и возможно написание фоллбека на более старые версии OpenGL, но не знаю пока, нужно ли оно.

делай для CUDA

Гений, ты сам-то видел производительность софтварной реализации в месе?

возьми GTK или EFL и приделай, что тебе не хватает

а в EFL оно точно не аппаратное?

но пока надо хотя бы на OpenGL 3.3 запилить.

Почему нужна именно версия 3.3?

Вообще, по-моему, может и 3.2 хватит, но не уверен. 3.3 чтобы использовать геометрические шейдеры и инстансинг. Да и вроде modern OpenGL это как раз с 3.3(ведь в нём стандартный граф. конвейер убрали, если мне не изменяет память)

Да и модно-молодёжно. И ещё это самая высокая версия, которую поддерживает Mesa

но оно (аппаратное ускорение в Qt) не используется по-умолчанию

ну так включи, приложение ж твоё

да и не у всех работает

А что, должно? Не под любым железом есть возможность и драйвера. Проще впилить в куте, чем писать с нуля.

Qt нельзя использовать из Си

Пиши сишный код внутри C++-ных конструкций. Никто не заставляет юзать С++-ные способы решения проблем сверх необходимости.

пришёл к выводу, что нужно

Пока что обоснование не впечатляет. Чем другие аналоги не подходят? Почему создание с нуля будет легче доработки аналогов?

Задача слишком масштабная, чтобы при таком уровне обоснования начинать.

Что есть:

http://en.wikipedia.org/wiki/Clutter_(software)

Что получить-то хочется? По ссылке описание частей Qt и GTK в смешанном порядке.

(Хорошо бы ответ был не «Qt, только чтобы быстро и красиво»)

У меня аппаратное ускорение в Qt тоже не работает, хотя видеокарта поддерживает OpenGL 4.2. Не работает ни с пропиретарными, ни со свободными драйверами.

Тем более Qt слишком толст по-моему.

Задача, кстати, не такая уж и масштабная, хотя, всё относительно.

а собственно, зачем? какой профит?

Скорее, GTK, только намного меньше, быстрее и с графическим ускорением.

Хочется получить легковесный GUI фреймворк с аппаратным ускорением. Желательно кроссплатформенный.

У меня аппаратное ускорение в Qt тоже не работает, хотя видеокарта поддерживает OpenGL 4.2. Не работает ни с пропиретарными, ни со свободными драйверами.

Вы нашли причину? Написали патч? Или не осилили?

Задача, кстати, не такая уж и масштабная

А теперь представь, что вместо исправления бага с неработающим ускорением тебе нужно пройти всё, что прошло Qt за годы работы большого числа квалифицированных людей. Или по-вашему они все были идиотами, и вы их шапками закидаете? Ну пусть не в одиночку, а во главе ватаги с ЛОРа.

Я не идеализирую Qt, я вообще в гуестроительстве не работаю, я критикую ваш подход в принципе.

Скорее, GTK, только намного меньше, быстрее и с графическим ускорением.

Это не лучше. В Qt уже есть аппаратное ускорение, просто нужно найти причину, по которой оно не работает в определенной конфигурации оборудования и ПО. Еще можно проверить, как оно работает с Wayland или Mir.

Я писал свой GUI (правда, несколько для других целей, но достаточно сложный и тоже на OpenGL), когда-то это казалось хорошей идеей (на платформе не было быстрого интерфейса с анимациями), но сейчас бы начинать не стал. Одна из причин — Qt.

Qt мне не подходит, причину искать не собираюсь и не собирался, на багтрекере вроде проблема уже открыта, qt используют у меня лишь два установленных приложения - qbittorrent и vlc.

Qt мне не подходит, т.к. на C++ я не писал, и не собираюсь. Уж очень многим он мне не нравится.

Я не считаю разработчиков Qt идиотами, успокойтесь. И не собираюсь я проходить весь путь Qt, я же не собираюсь копировать весь его функционал.

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

Версию OpenGL лучше не выше 2.1, чтоб работало на ноутах с интеграшкой от интела. В Thinkpad X220 (Sandy Bridge) glxinfo мне пишет OpenGL version string: 3.0 Mesa 9.2.1 OpenGL shading language version string: 1.30

В более старом ноуте intel 965 (x3100), там 2.1.

Аппаратно-ускоренный гуй закончится написанием игрового движка, т.к. для максимальной утилизации ресурсов нужны текстурные атласы, рендеринг кучей (in bulk), и отказ от ООП =)

Спасибо большое вам.

Но, про отказ от ООП я сомневаюсь. Хотя, я его и так не везде использую.

Тем более Qt слишком толст по-моему.

Это ты слишком толст, по-моему. Я за бан.

Qt мне не подходит, т.к. на C++ я не писал, и не собираюсь. Уж очень многим он мне не нравится.

То есть тебе слабо разобраться в сишных исходниках cairo, но и C++ тебе не нравится? Луддит 21-го века.

Аппаратно-ускоренный гуй закончится написанием игрового движка, т.к. для максимальной утилизации ресурсов нужны текстурные атласы, рендеринг кучей (in bulk), и отказ от ООП =)

А ещё нужен сопровождаемый код, что противоречит пункту про отказ от ООП.

Где-то в середине прошлого года кто-то делал основательное сравнение двух одинаковых и одним человеком писанных приложений на QML и EFL. Первое — декларативный скриптовый язык из Qt, второе — очень легковестная сишная библиотека. Как ни странно, производительность и потребление памяти оказались примерно равными. Там ещё главный разработчик EFL (Rasterman) потом ныл, что EFL нечестно сравнивали, потому что (sic!) не использовали хитрые хаки и пересборку для ускорения работы EFL конкретно в данном приложении.

Qt мне не подходит, т.к. на C++ я не писал, и не собираюсь.
Уж очень многим он мне не нравится.
т.к. на C++ я не писал
на C++ я не писал
он мне не нравится

/0

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

Вообще как совет — надо взять что-то из гтк/кутэ/етц, что умеет гл-контекст в окне, туда вкрутить sdl, и не ипстись с обвязкой. Я ходил по этим дорожкам, ты сначала протокол буфера обмена придумаешь, потом попробуешь оконные фичи собрать в «единую модель», потом dnd, потом окажется, что текстфилд не такая простая хрень, как кажется на первый взгляд, и вот уже мы видим в проекте подпапки x11/fb/win32/osx/ios/android/wp, каждая из которых весит не меньше, чем основной сорец. А еще оказывается есть directinput и мультимедия, которые тоже требуют встраивания в фреймворк.

Над проектами Qt и GTK+ трудятся сотни программистов целый десяток лет и их работа хоть как-то финансируется. Вы действительно считаете что небольшая группа девелоперов с ЛОРа сможет сделать хоть какой-нибудь конкурентоспособный продукт, на который с радостью перейдут все программисты-прикладники? Вы либо слишком молоды, либо слишком оптимистичны. Лучше пишите патчи в тот же GTK+ или Qt, раз обладаете необходимой для этого квалификацией.

Даже если не аппаратное, оно настолько шустрое, что разницы не видно.

Пожалуйста, не надо сообщений типа «не пиши велосипеды» или «не нужно»

ok

Да и в Си на Qt не попрограммировать вообще-то

Специально для вас, Козлов, есть GTK+.

Чё накинулись-то на человека? Хочет — пускай пишет. Just for fun. Или уже великие гуру с ЛОР решают, что кому писать, а что нет? Он что, вас заставляет что-то делать, отрывает вас от флуда на ЛОР?

Gl контекст в окне может GLFW(правда, я и сам могу gl context в окне запилить, но глядя на громадный исходник GLFW и свои 1,5 экрана кода, подозреваю, что что-то я делаю не так, хотя работает). С sdl не работал(ну только с SLD_sound, но я просто потыкал его и всё). Зачем протокол буфера обмена? В linux и так есть буфер обмена, даже два. DnD не нужен. Текстфилд вещь очень непростая, как представлю, в дрожь бросает.

Вообщем, есть желание - хорошо. Но вот что будет быстро результат, это я сомневаюсь.

Важно то, как представлен этот гуй в памяти. Можно прочитать удобный граф и разложить его по полкам для скармливания с учётом кэша и передачи большими блоками...

Ну, там в основном прямоугольники всё, вот я думал инстансинг использовать и геометрический шейдер для рисования по двум точкам, а не четырём. Или как-то ещё всё это ускорить можно?

Остальные базовые вещи (потоки и тп) может имеет смысл использовать из http://apr.apache.org/ , если glib слишком толсто. А ещё скорей всего понадобится использовать некоторые нативные контролы для ввода текста, если делать поддержку различных методов ввода или виртуальной клавы...

опенгл знаю поверхностно (писал простые шейдеры много лет назад), поэтому знаю только, что нужно передавать и обрабатывать данные большими неразрывными блоками для эффективного использования кэша, SIMD, передачи на карту, а для 2Д у нвидии есть супер лакомое расширение http://www.opengl.org/registry/specs/NV/path_rendering.txt, но только у нвідіі :(

Версию OpenGL лучше не выше 2.1, чтоб работало на ноутах с интеграшкой от интела.

Пока он допишет, в интеграшках уже давно будет 3.3