За два дня до выхода GNOME 3.16 представлен (https://mail.gnome.org/archives/gnome-announce-list/2015-Mar...) стабильный релиз новой ветки многоплатформенного тулкита для создания графического интерфейса пользователя - GTK+ 3.16.0 (http://www.gtk.org/). В состав тулкита входит полный набор виджетов, позволяющих использовать GTK+ для проектов различного уровня и размера. Код GTK+ развивается в рамках проекта GNU и распространяется под лицензией LGPL, что позволяет использовать GTK+ не только для разработки свободного ПО, но и для создания проприетарных приложений, не требуя от производителей закрытых программ выплаты роялти или покупки специальной лицензии. С тех пор, как GTK+ был разработан в рамках проекта GIMP, тулкит используется в различных проектах, например, GTK+ лежит в основе десктоп-окружений GNOME и Xfce или используется в таких продуктах, как Firefox и OpenOffice/LibreOffice.GTK+ спроектирован для поддержки не только C/C++, но и других языков программирования, таких как Perl и Python, что в сочетании с использованием визуального построителя интерфейса Glade (http://glade.gnome.org/) позволяет существенно упростить разработку и сократить время написания графических интерфейсов. Организация вывода в GTK+ абстрагирована от типа оконных систем, например, поставляется бэкенд, обеспечивающий возможность работы поверх дисплейного сервера Wayland, а также бэкенд, позволяющий отрисовывать вывод библиотеки GTK+ в окне web-браузера (запустив Gtk-приложение на одной машине, можно открыть web-браузер на другой машине и получить доступ к интерфейсу данной программы).
Из добавленных в GTK+ 3.16.0 улучшений (https://developer.gnome.org/gtk3/3.16/) можно отметить:
- В GDK (GIMP Drawing Kit) встроена поддержка OpenGL, которая позволяет организовать отрисовку через OpenGL без использования внешних надстроек. Для рендеринга через OpenGL представлен новый виджет GtkGLArea (http://www.mono-project.com/archived/gtkglarea/), который ранее распространялся в виде внешнего дополнения. В обиход введён новый тип объекта GdkGLContext, который позволяет прикрепить контекст OpenGL к определённому окну GdkWindow и использовать команды OpenGL для отрисовки произвольных элементов GTK+ в данном окне. Реализация позволяет использовать OpenGL для отрисовки в окружениях X11 и Wayland через libepoxy с использованием GLX или EGL.
<center><a href="http://www.bassi.io/images/gdk-gl-gears.png"><img src="http://www.opennet.me/opennews/pics_base/0_1413317486.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border="0"></a></center>
- В состав включён экспериментальный GDK-бэкенд,
обеспечивающий (https://developer.gnome.org/gtk3/3.16/gtk-mir.html) возможность работы поверх дисплейного сервера Mir. Бэкенд включает в себя около 5 тысяч строк кода и пока не собирается по умолчанию - для его сборки требуется указать опцию "--enable-mir-backend". Для запуска приложения с использованием данного бэкенда следует установить переменную окружения "GDK_BACKEND=mir";- Для объекта GtkStack реализован новый контроллер GtkStackSidebar (https://developer.gnome.org/gtk3/3.16/GtkStackSidebar.html), позволяющий создавать боковые панели;
<center><a href="https://developer.gnome.org/gtk3/3.16/sidebar.png">&... src="http://www.opennet.me/opennews/pics_base/0_1427086332.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
- Добавлен новый тип кнопок GtkModelButton (https://developer.gnome.org/gtk3/3.16/GtkModelButton.html), в которых в качестве модели выступает GAction;
- В объект GtkPopover добавлен подкласс GtkPopoverMenu (https://developer.gnome.org/gtk3/3.16/GtkPopoverMenu.html), упрощающий создание кнопок в заголовке окна (popover) в форме меню;
- Переработаны компоненты, отвечающие за прокрутку содержимого окон. Добавлена поддержка перекрытия (overlay) полос прокрутки. Обеспечена возможность индикации запрета прокрутки ('scrolled off'). Представлены новые сигналы "::edge-reached" и "::edge-overshot", а также новое правило GTK_POLICY_EXTERNAL, например, позволяющее реализовать сдвиг без видимых полос прокрутки.
- Удалены или объявлены устаревшими вызовы: gdk_window_set_static_gravities, gdk_window_set_composited,
gtk_style_context_get_background_color, gtk_style_context_get_border_color,
gtk_settings_set_string/long/double_property, gtk_settings_install_property,
GtkStyleProperties, gdk_cursor_new, gdk_*_libgtk_only,
GtkCellRendererPixbuf::follow-state.URL: https://mail.gnome.org/archives/gnome-announce-list/2015-Mar...
Новость: http://www.opennet.me/opennews/art.shtml?num=41890
Вчера обновил Homebank до версии 5, который использует GTK+3, это какой-то кошмар, смотреть без слез на этот ужас нельзя!
Почти как настоящий банк. Тормозит на слабых камнях, зато с свежим ремон^W^W красивыми иконками. А теперь можно и с 3д-анимацией.
> Вчера обновил Homebank до версии 5, который использует GTK+3, это какой-то кошмар,
> смотреть без слез на этот ужас нельзя!
>
> Почти как настоящий банк. Тормозит на слабых камнях, зато с свежим ремон^W^W красивыми
> иконками. А теперь можно и с 3д-анимацией.1. тормозит -- прям вот именно из-за GTK3 ? точно-точно определил причину?
2. "на слабых камнях" -- кому какая разница что там происходит на слабых камнях.
лишь бы не тормозило бы на *обычных* компьютерах..
а на "слабых камнях" -- запускай специальные программы (написанные для "слабых камней").ни кто (просто так, специально для тебя) не станет переписывать *обычную* программу (предназначенную для *обычных* компьютеров) -- в программу которая будет предназначена для твоего нестандартного компьютера.
откуда вообще такие наглые пользователи пошли.. вы договаривались с программистом чтобы эта программа была бы адоптирована для вашего необычного железа? вы платили программистам за эту работу (никому не нужную кроме вас работу, так как у всех остальных *обычные* компьютеры)? вы просто хотите чтобы программисты от-делать-нечего просто-так сделали бы что-то для вас (и только для вас, нокому больше это не нужно), может потому что вы считаете что эти программисты вам что-то должны?
> 2. "на слабых камнях" -- кому какая разница что там происходит на
> слабых камнях.
> лишь бы не тормозило бы на *обычных* компьютерах..
> а на "слабых камнях" -- запускай специальные программы (написанные для "слабых камней").Нужно просто нормально подходить к написанию софта - без overhead/overkill/overengineering и расходовать столько ресурсов, сколько реально необходимо для конкретной задачи. А то напишут очередной "блокнот", пооптимизируют, что бы на среднем четырех ядернике не сильно тормозил и думают, что это нормально.
Слабый камень это не только морально устаревший. Он может быть дешевым, энергоэффективным, легким и компактным.
> Слабый камень это не только морально устаревший. Он может быть дешевым, энергоэффективным, легким и компактным.справедливое замечение!
однако надо и не забывать что старые компьютеры -- могут в несколько раз (именно в несколько раз, а не на несколько десятков процентов) быть слабее чем современные энергоэффективные двухядерные.
> однако надо и не забывать что старые компьютеры -- могут в несколько
> раз (именно в несколько раз, а не на несколько десятков процентов)
> быть слабее чем современные энергоэффективные двухядерные.Согласен, но повышенная энергоэффективность (на десктопах) не окупится, так как затраты на электроэнергию меньше, чем апгрейд (+ производство нового и утилизация старого железа).
Намекаете, что ваше время ничего не стоит? Ну так, если вам не лень ждать машину...
> Намекаете, что ваше время ничего не стоит? Ну так, если вам не
> лень ждать машину...Речь о системах с равной производительностью, но разным энергопотреблением.
Что же касаемо скорости системы - то тут все очень сильно зависит от задачи (и кривости приложений). Мне в большинстве случаев хватает старого ноута (1.66Mhz x 2, 2GB), но для рендеринга не хватает и десктопного процессора (3.5Mhz x 4), только OpenCL спасает ситуацию.
> 1. тормозит -- прям вот именно из-за GTK3 ? точно-точно определил причину?Отойдём немного в сторону. evince 2.x и evince 3.x. Первый собран с gtk-2, второй с gtk-3. У первого на i5 список превью 100-страничной pdf в панели слева скроллится без видимых тормозов. У второго движется с раздражающими лагами. Уверен, проблема в gtk-3.
>> 1. тормозит -- прям вот именно из-за GTK3 ? точно-точно определил причину?
> Отойдём немного в сторону. evince 2.x и evince 3.x. Первый собран с
> gtk-2, второй с gtk-3. У первого на i5 список превью 100-страничной
> pdf в панели слева скроллится без видимых тормозов. У второго движется
> с раздражающими лагами. Уверен, проблема в gtk-3.спасибо, конечно, за проявление этой уверенности..
уверен, что многие люди своей уверенностью добиваются определённых результатов! (например можно придти в кабинет начальника и уверенно сказать: "уверен, что я должен получать зарплату больше чем сейчас!" -- и это может прокатить успешно! :)). но здесь у нас не окологуманитарное отделение форума, и не контора по заключению пари.. :) поэтому мы рассмотрим всё более детально!
то есть тут ты пытаешься намекать что кроме GTK-2=>GTK-3 -- других изменений (в частности в движок рендеренга PDF) ни каких не было в Evince-2=>Evince-3 ? :-)
...и ещё ты хочешь сказать что тормозит (лагает) БАНАЛЬНО ОБЫЧНАЯ прокрутка отрисованной поверхности? думаешь GTK3 не способен справится с этой типовой задачей без лагов? :-)
То есть более свежая версия программы менее оптимизирована? При прочих равных (один документ). Тогда это не прогресс, а регрессия.
если вся твоя активность -- определятся только этим одним документом -- то быть может да. в данной ситуации это можно было бы рассмотреть как регресс.но вопрос в том стали ли другие документы (и на других компьютерах с другими видокартами) -- тоже работать в новой версии хуже %) %)
а когда повится Wayland -- то нужно будет ещё раз провести все эти тесты производительности [например: насколько "быстро" работает Evince-2 в режиме XWayland -- в сравнении с -- Evince-3 в режиме Native-Wayland ]
> Отойдём немного в сторону. evince 2.x и evince 3.x. Первый собран с
> gtk-2, второй с gtk-3. У первого на i5 список превью 100-страничной
> pdf в панели слева скроллится без видимых тормозов. У второго движется
> с раздражающими лагами. Уверен, проблема в gtk-3.Для полной уверенности нужно протировать gtkperf на gtk3. Есть желающие попробовать?
Можно попробовать профайлером локализовать тормозящее место. Есть очень простой в использовании профайлер - sysprof (http://sysprof.com).
Парочка баянов:
http://www.linux.org.ru/forum/talks/7592498
http://www.linux.org.ru/forum/talks/8457099
yum downgrade
dnf downgrade, дедушка.
> gdk_window_set_static_gravities ...Трехэтажненько.
не прошло и двадцати лет, как аноним обратил внимание...
Энтерпрайз.
Большая либа + C - результат закономерен. Плата за эмуляцию классов.
Просто не очень хороший принцип форматирования названий. Ведь можно назвать так:
gdkWindow_setStaticGravities, что мало отличается от gdkWindow.setStaticGravities.
Всем бы вам, любителям CamelCase, да запихнуть его везде.
В те времена, когда GTK только рождался, не было моды на верблюжатину.
Её и сейчас не везде уважают. На Python часто разделяют слова подчёркиванием. Читается и набирается проще, чем какое-нибудь XMLHttpRequest.
> Её и сейчас не везде уважают. На Python часто разделяют слова подчёркиванием.
> Читается и набирается проще, чем какое-нибудь XMLHttpRequest.И это хорошо. Пускай оно остаётся в Java, или откуда бы там еще оно не вылезло.
> набирается прощеЧто Shift+- для подчёркивания, что Shift+буква для CamelCase -- один фиг. Читабельность так и вовсе штука в немалой степени субъективная. Тут больше личных предпочтений и принятых в конкретном проекте правил (т.е., по большому счёту, тех же личных предпочтений руководител{я|ей}), чем каких-то объективных факторов.
> Всем бы вам, любителям CamelCase, да запихнуть его везде.Вас никто не заставляет его использовать. ИМХО мой вариант читается лучше, так как явно отделяет класс от функции.
> В те времена, когда GTK только рождался, не было моды на верблюжатину.
OpenGL Initial release: January 1992.
glBegin, glEnd, glArrayElement ...
>gdkWindow_setStaticGravitiesГде-то были исследования, что КэмелКейс читается хуже чем снейк_кейс.
>>gdkWindow_setStaticGravities
> Где-то были исследования, что КэмелКейс читается хуже чем снейк_кейс.http://tproger.ru/translations/camelcase-vs-underscores-scie.../
Оно?
Так оно и удалено.
> GTK+ с возможностью отрисовки через OpenGLДАЛАДНА! Через 8 лет после того, как этому научился Qt!
> ДАЛАДНА! Через 8 лет после того, как этому научился Qt!Вообще-то, в Gtk+ был/есть Clutter, который, по крайней мере, уже в 2008 году позволял использовать отрисовку через OpenGL: http://www.freshports.org/graphics/clutter/
Нормальный человек даст ссылку на сайт проекта. Но бздуны...
По приведённой ссылке есть всё: ссылка на сайт разработчиков и история изменения версий, начиная с той, с которой заработала заявленная функциональность во FreeBSD. К сожалению, моя картина мира не содержит фактов работы библиотеки версий ниже, чем указана в истории порта (сопровождаю FreeBSD с лета 2006 года). Может на линуксах и раньше работала - кто знает?
> По приведённой ссылке есть всёТолько надо потратить в 2 раза больше времени на копание в нафигнужном крапе. А потом некоторые удивляются: почему кто-то считает что бздуны все делают контрпродуктивно и криво?!
>> По приведённой ссылке есть всё
> Только надо потратить в 2 раза больше времени на копание в нафигнужном крапе.По приведённой ссылке информация имеет свойство полноты, ясности и однозначности.
Если у тебя синдром рассеянного внимания, не переходи по ней, умоляю.> А потом некоторые удивляются: почему кто-то считает что бздуны все
> делают контрпродуктивно и криво?!Это линуксоиды всё переусложняют и вываливают кучу левосторонних ссылок вместо одной нужной.
в gtk2 эта возможность была сколько себя помню (через gtkglext)
> в gtk2 эта возможность была сколько себя помню (через gtkglext)gtkglext позволяет отрисовывать собственную графику через OpenGL. При этом виджеты gtk отрисовываются через xlib. Ранее были попытки перевести cairo на OpenGL (glitz), но насколько помню все так и осталось на уровне альфы.
>> в gtk2 эта возможность была сколько себя помню (через gtkglext)
> gtkglext позволяет отрисовывать собственную графику через OpenGL. При этом виджеты gtk
> отрисовываются через xlib. Ранее были попытки перевести cairo на OpenGL (glitz),
> но насколько помню все так и осталось на уровне альфы.а эта новость, по-твоему, про что? на скриншоте демонстрируется виджет GtkGLArea, являющийся заменой gtkglext.
> и использовать команды OpenGL для отрисовки произвольных элементов GTK+ в данном окне.На скриншоте видно, что полупрозрачный элемент перекрывает элементы управления.
>> и использовать команды OpenGL для отрисовки произвольных элементов GTK+ в данном окне.
> На скриншоте видно, что полупрозрачный элемент перекрывает элементы управления.это называется compositing
(кстати, в месте перекрытия, на стыке с opengl-виджетом виден баг)и да, этот opengl виджет нужен как раз для этого: "использовать команды OpenGL для отрисовки произвольных элементов GTK+ в данном окне."
как и gtkglext. не вижу противоречий.
(если не считать кривого перевода, т.к. в оригинале написано: GtkGLArea — A widget for custom drawing with OpenGL)
Про GtkGLArea верно. Речь о GdkWindow. Насколько я понимаю теперь все может отрисовываться через OpenGL:> This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it.
> Про GtkGLArea верно. Речь о GdkWindow. Насколько я понимаю теперь все может
> отрисовываться через OpenGL:
>> This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it.Насколько я понимаю всю эту кухню, речь идет об инфраструктуре внутри GDK, которая нужна для GtkGLArea и подобных. Рисование "обычных" виджетов происходит через cairo в любом случае. Чтобы виджеты рисовали через opengl -- их нужно будет специальным образом переделывать. Это никак не касается существующих виджетов.
> Насколько я понимаю всю эту кухню, речь идет об инфраструктуре внутри GDK,
> которая нужна для GtkGLArea и подобных. Рисование "обычных" виджетов происходит через
> cairo в любом случае.Нет. GdkWindow это базовое окно, через которое отрисовывается GtkWindow и остальные виджеты.
> Чтобы виджеты рисовали через opengl -- их
> нужно будет специальным образом переделывать. Это никак не касается существующих виджетов.Переделывать не нужно, достаточно подменить часть отвечающую за примитивы. Иначе было бы не возможно отрисовывать виджеты внутри браузера или в wayland (без xlib).
>> Насколько я понимаю всю эту кухню, речь идет об инфраструктуре внутри GDK,
>> которая нужна для GtkGLArea и подобных. Рисование "обычных" виджетов происходит через
>> cairo в любом случае.
> Нет.O_O
> Переделывать не нужно, достаточно подменить часть отвечающую за примитивы. Иначе было бы
> не возможно отрисовывать виджеты внутри браузера или в wayland (без xlib).не путай теплое с мягким. opengl есть и в иксах, и в вяленом. и новость как раз про то, как использовать opengl в отдельно взятых виджетах. причем там же, в новости, конкретно упоминается, что в данный момент это работает только с иксовым и вяленым бакендами: "currently
this is implemented for X11 and Wayland using libepoxy"
> не путай теплое с мягким. opengl есть и в иксах, и в
> вяленом. и новость как раз про то, как использовать opengl в
> отдельно взятых виджетах.Применительно к GtkGLArea - да. Но не к GdkWindow.
Как по-вашему происходит отрисовка GtkButton (и остальных виджетов) на wayland?
>> не путай теплое с мягким. opengl есть и в иксах, и в
>> вяленом. и новость как раз про то, как использовать opengl в
>> отдельно взятых виджетах.
> Применительно к GtkGLArea - да. Но не к GdkWindow.
> Как по-вашему происходит отрисовка GtkButton (и остальных виджетов) на wayland?в точности так же, как на любом другом бакенде.
если тебе самому влом посмотреть в код, то: gtk_render_background, gtk_render_frame, gtk_render_focus, + вызовом метода родительского класса (GtkBin), который дергает отрисовку contained widgets. и все это через каиру.
Я имел ввиду другое: если используешь wayland, то все виджеты рисуешь через OpenGL.
> Я имел ввиду другое: если используешь wayland, то все виджеты рисуешь через
> OpenGL.я потерял нить твоих рассуждений на этом месте.
>> Я имел ввиду другое: если используешь wayland, то все виджеты рисуешь через
>> OpenGL.
> я потерял нить твоих рассуждений на этом месте.В wayland все выводится через OpenGL, другого средства 2d ускорения не предусмотрено.
>>> Я имел ввиду другое: если используешь wayland, то все виджеты рисуешь через
>>> OpenGL.
>> я потерял нить твоих рассуждений на этом месте.
> В wayland все выводится через OpenGL, другого средства 2d ускорения не предусмотрено.omg, ну и причем тут это? ты в коде рисуешь все через каиру. все операции рисования в cairosurfaces - не через opengl. то что wayland потом все это дело композитит через opengl -- совсем другая история. извини, чувак, мне больше с тобой не о чем говорить.
>>>> Я имел ввиду другое: если используешь wayland, то все виджеты рисуешь через
>>>> OpenGL.
>>> я потерял нить твоих рассуждений на этом месте.
>> В wayland все выводится через OpenGL, другого средства 2d ускорения не предусмотрено.
> omg, ну и причем тут это? ты в коде рисуешь все через
> каиру. все операции рисования в cairosurfaces - не через opengl. то
> что wayland потом все это дело композитит через opengl -- совсем
> другая история. извини, чувак, мне больше с тобой не о чем
> говорить.Не извиню :) Композит тут не причем. Как cairo рисует линии и прямоугольники в wayland?
>[оверквотинг удален]
>>>>> OpenGL.
>>>> я потерял нить твоих рассуждений на этом месте.
>>> В wayland все выводится через OpenGL, другого средства 2d ускорения не предусмотрено.
>> omg, ну и причем тут это? ты в коде рисуешь все через
>> каиру. все операции рисования в cairosurfaces - не через opengl. то
>> что wayland потом все это дело композитит через opengl -- совсем
>> другая история. извини, чувак, мне больше с тобой не о чем
>> говорить.
> Не извиню :) Композит тут не причем. Как cairo рисует линии и
> прямоугольники в wayland?я понятия не имею, но скорее всего попиксельно в буфере (без аппаратного ускорения).
> я понятия не имею, но скорее всего попиксельно в буфере (без аппаратного
> ускорения).В 21-ом веке :) Через xlib > ddx > eax/sna > drm > kms или xlib > ddx > glamor > opengl > drm > kms. Теперь будет через opengl > drm > kms как для wayland, так и для Xorg.
>> я понятия не имею, но скорее всего попиксельно в буфере (без аппаратного
>> ускорения).
> В 21-ом веке :) Через xlib > ddx > eax/sna > drm
> > kms или xlib > ddx > glamor > opengl >
> drm > kms. Теперь будет через opengl > drm > kms
> как для wayland, так и для Xorg.да хоть в 31м. пруфы будут?
> да хоть в 31м. пруфы будут?Отключи eax/san и запусти gtkperf.
Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).
http://cairographics.org/
>> да хоть в 31м. пруфы будут?
> Отключи eax/san и запусти gtkperf.ты понимаешь, что ты щас пытаешься зачем-то доказывать, что каира в вяленде рисует графику через xlib?
> ты понимаешь, что ты щас пытаешься зачем-то доказывать, что каира в вяленде
> рисует графику через xlib?У тебя wayland? Я написал как самому проверить, есть 2d ускорение в gtk/cairo или нет.
Для wayland отрисовка всегда идет через opengl иначе будет очень медленно.
>> ты понимаешь, что ты щас пытаешься зачем-то доказывать, что каира в вяленде
>> рисует графику через xlib?
> У тебя wayland? Я написал как самому проверить, есть 2d ускорение в
> gtk/cairo или нет.у меня макось в данный момент.
> Для wayland отрисовка всегда идет через opengl иначе будет очень медленно.
что ты под этим подразумеваешь?
я предоставлю тебе возможность выбрать из нескольких вариантов:
* gtk виджеты рисуют напрямую через opengl минуя каиру
* каира использует opengl-бакенд
* каира рисует как обычно, но композитинг производится средствами opengl
* все вышеперечисленное
* свой вариант?
> у меня макось в данный момент.Все что я пишу справедливо для linux, как у мака построена графическая подсистема я не знаю.
>> Для wayland отрисовка всегда идет через opengl иначе будет очень медленно.
> что ты под этим подразумеваешь?Компоузинг окон идет через OpenGL, за это отвечает weston, тулкит отвечает только за отрисовку внутри окна.
GdkWindow создает окно с контекстом OpenGL. Рисовать в нем можно только через OpenGL, соответственно cairo использует GL_LINE/GL_QUADS/etc (opengl-бакенд) для отрисовки примитивов. Виджеты используют cairo.
>> у меня макось в данный момент.
> Все что я пишу справедливо для linux, как у мака построена графическая
> подсистема я не знаю.
>>> Для wayland отрисовка всегда идет через opengl иначе будет очень медленно.
>> что ты под этим подразумеваешь?
> Компоузинг окон идет через OpenGL, за это отвечает weston, тулкит отвечает только
> за отрисовку внутри окна.
> GdkWindow создает окно с контекстом OpenGL. Рисовать в нем можно только через
> OpenGL, соответственно cairo использует GL_LINE/GL_QUADS/etc (opengl-бакенд) для отрисовки
> примитивов. Виджеты используют cairo.т.е., ты выбрал вариант
> каира использует opengl-бакенд
пруфы будут?
> пруфы будут?http://www.linuxfromscratch.org/blfs/view/svn/x/cairo.html
--enable-gl: This switch enables Cairo's experimental OpenGL surface which is required for Wayland compositor
>> пруфы будут?
> http://www.linuxfromscratch.org/blfs/view/svn/x/cairo.html
> --enable-gl: This switch enables Cairo's experimental OpenGL surface which is required
> for Wayland compositorосталось предоставить пруф, что это действительно работает в wayland+gtk, да еще и по-умолчанию, и никак иначе (ты ведь это пытаешься доказать?)
и, надеюсь, ты понимаешь, что "opengl surface" != "все операции cairo транслируются в GL_LINES/GL_QUADS/...", да? это вообще может значить что угодно.
иными словами, опция configure --enable-gl _НЕ_ включает opengl backend, а просто добавляет поддержку рисования в opengl surface. а рисовать в оный surface можно как угодно, совсем не обязательно через opengl.
в итоге, мы возвращаемся к тому, что я выше и написал -- opengl используется для композитинга, и не более.
>>> пруфы будут?
>> http://www.linuxfromscratch.org/blfs/view/svn/x/cairo.html
>> --enable-gl: This switch enables Cairo's experimental OpenGL surface which is required
>> for Wayland compositor
> осталось предоставить пруф, что это действительно работает в wayland+gtk, да еще и
> по-умолчанию, и никак иначе (ты ведь это пытаешься доказать?)
> и, надеюсь, ты понимаешь, что "opengl surface" != "все операции cairo транслируются
> в GL_LINES/GL_QUADS/...", да? это вообще может значить что угодно.Расскажи мне, как рисовать на opengl surface, не использую opengl? ;)
> иными словами, опция configure --enable-gl _НЕ_ включает opengl backend, а просто добавляет
> поддержку рисования в opengl surface. а рисовать в оный surface можно
> как угодно, совсем не обязательно через opengl../configure --help
--enable-gl=[no/auto/yes] Enable cairo's OpenGL surface backend feature> в итоге, мы возвращаемся к тому, что я выше и написал --
> opengl используется для композитинга, и не более.The client links to a rendering library such as OpenGL that knows how to program the hardware and renders directly into the buffer.
Все, устал я, читай:
http://wayland.freedesktop.org/architecture.html
> Расскажи мне, как рисовать на opengl surface, не использую opengl? ;)рисуешь как угодно в буфер, потом средствами opengl копируешь данные в opengl surface.
>> иными словами, опция configure --enable-gl _НЕ_ включает opengl backend, а просто добавляет
>> поддержку рисования в opengl surface. а рисовать в оный surface можно
>> как угодно, совсем не обязательно через opengl.
> ./configure --help
> --enable-gl=[no/auto/yes] Enable cairo's OpenGL surface backend featureэто _surface_ backend, а не _rendering_ backend. разницу чувствуешь?
> The client links to a rendering library such as OpenGL that knows
> how to program the hardware and renders directly into the buffer.нерелевантно.
> Все, устал я, читай:
> http://wayland.freedesktop.org/architecture.htmlрад был закончить этот бессмысленный разговор.
когда у тебя будет пруф, что в вяленде виджеты GTK рисуются примитивами opengl -- возвращайся.
копирование готового буфера в opengl surface не засчитывается.
>>> Насколько я понимаю всю эту кухню, речь идет об инфраструктуре внутри GDK,
>>> которая нужна для GtkGLArea и подобных. Рисование "обычных" виджетов происходит через
>>> cairo в любом случае.
>> Нет.
> O_OCairo уже умеет отрисовывать через OpenGL/EGL. Насколько я понимаю оставалось только научить базовое окно (GdkWindow) тоже использовать OpenGL и получить полную отрисовку всего через OpenGL - "to use OpenGL to draw everything".
>>>> Насколько я понимаю всю эту кухню, речь идет об инфраструктуре внутри GDK,
>>>> которая нужна для GtkGLArea и подобных. Рисование "обычных" виджетов происходит через
>>>> cairo в любом случае.
>>> Нет.
>> O_O
> Cairo уже умеет отрисовывать через OpenGL/EGL. Насколько я понимаю оставалось только научить
> базовое окно (GdkWindow) тоже использовать OpenGL и получить полную отрисовку всего
> через OpenGL - "to use OpenGL to draw everything".угу, наверное. но в новости об этом ни слова :)
> угу, наверное. но в новости об этом ни слова :)Все там есть, только не отделено от GtkGLArea, что и вводит в заблуждение.
> В обиход введён новый тип объекта GdkGLContext, который позволяет прикрепить контекст OpenGL к определённому окну GdkWindow и использовать команды OpenGL для отрисовки произвольных элементов GTK+ в данном окне.
Ну вот, собирался сегодня достать из пыльного шкафа системник с Арчем, расчехлить, обновить, может даже третегном поставить. Теперь не буду, пусть всё это продолжает гореть в Аду.
> В GDK (GIMP Drawing Kit) встроена поддержка OpenGLДа, но нужно ведь иметь OpenGL 3.2! А это всё ещё не так просто. Вот 2.1 - реально.
