Кто-нибудь разбирался с этим OpenVG? Как впечатления?

Qt 4.3 ещё в глубокой разработке, а AP уже 4.3.1 приплёл :) Там в оригинале I а не 1.

Обман зрения =) Виноват, каюсь =)

А вот запись на блоге Зака:

http://zrusin.blogspot.com/2007/01/openvg_116899762231694078.html

В догонку

Дожили .... низкоуровневый интерфейс ... через Qt ;)

Да плюсисты любой интерйфейс через .... Qt реализуют;) "Если все, что у тебя есть, это молоток - всё вокруг выглядит гвоздями"

Там, кстати, в блоге Uraeus задает правильный вопрос. Только я надеюсь не дожить до того момента, как в Xorg появится зависимость от Qt...

Учитывая что троли собираются реализовать поддержку OpenGL|ES в Qt4.3, то реализация OpenVG поверх Qt не кажется такой идиотской. К тому же Зак там работает.

Держу пари, что гномовцы реализовали бы это поверх Cairo.

``The main reason for it is that QtOpenGL, quality and speed wise (in Qt 4.3) beats everything out there - every vector graphics framework.''

>Да плюсисты любой интерйфейс через .... Qt реализуют;) "Если все, что у тебя есть, это молоток - всё вокруг выглядит гвоздями"

... I did it on top of QtOpenGL. The main reason for it is that QtOpenGL, quality and speed wise (in Qt 4.3) beats everything out there - every vector graphics framework ...

http://zrusin.blogspot.com/2007/01/openvg_116899762231694078.html

:)

Насколько я заметил, Зак -- один из разработчиков Qt. Если вдумчиво почитать его блог, можно заметить рассказ о том, как за вечер в Qt были добавлены режимы наложения из SVG 1.2 (Портера-Даффа и прочие). ИМХО, Qt становится всё более приятным тулкитом. Кто б на нём FontForge переписал... Ну или на Cairo/Gtk+ -- один фиг, лишь бы выглядело по-человечески =)

Cairo - не гномовская технология. Это технология freedesktop.org - т.е. кросс-десктопная. А вообще - если уж делать не-аппаратно ускоренную реализацию OpenVG - то поверх голого OpenGL. Вот нафига Заку была нужна кутешная прослойка QtOpenGL? По привычке к плюсам? Разучился ваять функции, не приндлежащие какому-нибудь классу?;)

QtOpenGL - это надстройка над OpenGL. Не будет же Зак утверждать, что надстройка работает быстрее и качественней, чем нижний уровень?

Приятный тулкит. На плюсах. Ню-ню..;)

> Cairo - не гномовская технология.

+1

http://rants.scribus.net/2006/05/20/cairo-vs-libart/
http://rants.scribus.net/2006/05/28/layer-transparency-revisited/

>QtOpenGL - это надстройка над OpenGL. Не будет же Зак утверждать, что надстройка работает быстрее и качественней, чем нижний уровень?

В той же степени, что и cairo по отношению к X Render Extension. То есть операции высокого уровня (отсечение по пути, размывание, и т.д.) делал Зак. И сделал так, что сравнение с остальными превращается в избиение младенцев.

Я так понимаю, OpenVG - это 2d графика. Просто рисуется оно через QPainter и OpenGL подсистему.

>Приятный тулкит. На плюсах. Ню-ню..;)

Да разразится святой флейм c vs c++. :) А что благородный Дон имеет против плюсов ? :)

> Не будет же Зак утверждать, что надстройка работает быстрее и качественней, чем нижний уровень?

Рассмотри ситуацию, когда надстройка предоставляет до предела оптимизированные расширенные примитивы, отсутствующие ниже, но облегчающие реализацию всего выше.

;)

>Зак Расин (Zack Rusin)

А точно Расин? Может Русин? Слог вроде открытый.

Кстати, да.

А в чем отличие OpenGL от OpenVG?

> Его реализация основана на QtOpenGL (Qt 4.3.1)

т.е. фактически это для Qt и KDE программ?

> QtOpenGL - это надстройка над OpenGL. Не будет же Зак утверждать, что надстройка работает быстрее и качественней, чем нижний уровень?

svu, Вы вроде раньше производили впечатление грамотного врага C++, а сейчас ляпы делается. QtOpenGL - это привязка OpenGL к оконной системе. Собственно OpenGL-код одинаков везде - glBegin(); glVertex3f(); glEnd() никуда не деваются и вызываются напрямую. Задачу Qt - создать контекст, связать его с окном и т.д. и т.п. Ну не нравится Вам Qt - возьмите GLUT. или по-Вашему GLUT тоже замедляет вывод OpenGL?

> т.е. фактически это для Qt и KDE программ?

Не думаю. Вам не все равно, каким именно методом отрисовываются примитивы в окне? API OpenVG, насколько я могу судить, соответствует стандарту, а чем конкретно оно рисует - программе и знать не обязательно.

Кстати, внутри OpenVG вообще не обязательно лежит OpenGL. Технология разрабатывается для встраиваемых систем, куда полноценный OpenGL тащить незачем, а использовать 2D-ускоритель для отрисовки каких-нибудь карт или флешек может оказаться весьма выгодно.

>> Его реализация основана на QtOpenGL (Qt 4.3.1)

>т.е. фактически это для Qt и KDE программ?

Нет

Ок, тогда, возможно, я неточно представляю роль QtOpenGL. Если это ТОЛЬКО плюсовая обертка вокруг OpenGL - мое утверждение в силе. Если там реализуется некая доп. функциональность, отсутствующая в OpenGL - мое утверждение снимается. Правда, тогда остается сожаление, что реализация OpenVG зависит от кода, повязанного на плюсовую технологию...

Ребят, кто из вас чей виртуал?;)

Что OpenGL везде один и то же - я в курсе. Непонятки были в роли QtOpenGL. Привязка к окнам - это довольно небольшой кусок кода и действительно ничего не замедляет. А вот плюсовая обертка вокруг OpenGL вызовов - дает некое performance penalty на каждый не-inline вызов... Моя мысль была в том, что лучше б вообще без оберток для OpenGL...

Грубо говоря - я не уверен, что плюсовая программа, использующая QtOpenGL, вызывает непосредственно glBegin - а не какой-нибудь метод какого-то класса, который вглубине себя вызывает glBegin. Вы можете ответить на этот вопрос пожалуйста?

В тикле это реализовано как TkZinc ;) И без кутей, на сях.

>Нет

Да

"The implemention is licensed under GNU GPL v2 license and depends on the cross-platform Qt library."

Тем не менее

"All in all, the dependency on Qt and the license could change."

Я сам себе виртуал :-)

> Ок, тогда, возможно, я неточно представляю роль QtOpenGL. Если это ТОЛЬКО плюсовая обертка вокруг OpenGL

Это вообще НЕ обертка над OpenGL. Вкратце, ситуация обстоит так. OpenGL предоставляет средства для задания координат вершин, их цветов, положений источников освещения и т.д. и т.п. При этом OpenGL (как стандарт) абсолютно и полностью не интересует, где именно этот треугольник будет отоборажаться - в смысле, в каком реально окне на экране будет нарисован примитив. Этим (естественно) занимаются платформенно-зависимые части - под виндой этой Wgl, в X тоже есть аналогичное расширение, название которого я не помню :(. Напрямую оно используется редко - ибо муторно - поэтому обычно используют оконные библиотеки вроде GLUT, которые привязывают контекст OpenGL к конкретному окну, попутно за клавиатурным/мышастым вводом-выводом следят и т.п. QtOpenGL - как раз из этой оперы. То есть, его задача - связать GL-виджет с X-окном, сообщить виджету, что по нему щелкнули мышью и т.п. OpenGL при этом совершенно ничем не оборачивается.

>ИМХО, Qt становится всё более приятным тулкитом

Вероотступник! ;)

>Кто б на нём FontForge переписал... Ну или на Cairo/Gtk+ -- один фиг, лишь бы выглядело по-человечески =)

"Кто куды а мы к зайцам!" (с)

> Грубо говоря - я не уверен, что плюсовая программа, использующая QtOpenGL, вызывает непосредственно glBegin - а не какой-нибудь метод какого-то класса, который вглубине себя вызывает glBegin. Вы можете ответить на этот вопрос пожалуйста?

Именно glBegin() оно и вызывает - напрямую. Желающие могут сделать обертку и над вызовами gl*, но в Qt их нет.

Принято. "Был неправ, вспылил" (с) Хотя и жаль, что не glut;)

> "The implemention is licensed under GNU GPL v2 license and depends on the cross-platform Qt library."

Естественно, сама реализация требует Qt для работы. При этом приложению, использующему OpenVG сам Qt по боку - его вызовы OpenVG интересуют.

Грубо говоря, все программы для Linux требуют, чтобы в системе было установлено ядро Linux. Для системных вызовов. Но, при этом, если я аккуратно пишу на том же Glib, для меня это неявная зависимость. Это проблема GLib, а я уже буду зависеть от Glib. Никто не требует от моей программы делать магический mov ax, ;syscall no ... int 80h, также и от приложения OpenVG никто не требует быть Qtшным.

> Принято. "Был неправ, вспылил" (с) Хотя и жаль, что не glut

Таки уж и жаль? ;-) Он, насколько я помню, несводобный.

>Напрямую оно используется редко - ибо муторно - поэтому обычно используют оконные библиотеки вроде GLUT

По моим наблюдениям, glut используют реже всего. Чаще всё-таки используют GLX напрямую, либо SDL (как замену GLUT).

> По моим наблюдениям, glut используют реже всего. Чаще всё-таки используют GLX напрямую, либо SDL (как замену GLUT).

Очень может быть. Мне он в первую очередь приходит в голову ибо (как и GLU) уже воспринимается как часть OpenGL. ;-) Суть от этого не меняется - большая часть виденных мною программ так или иначе использует обертку над GLX.

freeglut?

> Ок, тогда, возможно, я неточно представляю роль QtOpenGL.

``The Qt OpenGL module is implemented as a platform-independent Qt/C++ wrapper around the platform-dependent GLX, WGL, or AGL C APIs. The functionality provided is very similar to Mark Kilgard's GLUT library, but with much more non-OpenGL-specific GUI functionality, i.e. the whole Qt API.''

> freeglut?

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

Ланн, нехай будет SDL.

>> freeglut?

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

Да я вижу, тут грамотные эксперты собрались! На темы OpenGL рассуждают, а даже того не знают, что freeglut давны-давно является той реализацией GLUT, которая входит во все дистрибутивы.

А вообще, писать хоть сколько-нибудь серьёзное ПО с использованием GLUT сегодня будет только сумасшедший.

> Ланн, нехай будет SDL.

SDL и GLUT --- это вещи, предназначенные для решения совершенно разных задач. Дял того, чтобы это понять, достаточно расшифровать их аббревиатуры. Сравнивать их --- это всё равно, что сравнивать, скажем, GTK+ и DirectX.

SDL действительно довольно часто используется как кросс-платформенная обвязка GL- и не более. Как и GLUT

> Да я вижу, тут грамотные эксперты собрались! На темы OpenGL рассуждают, а даже того не знают, что freeglut давны-давно является той реализацией GLUT, которая входит во все дистрибутивы.

А в чем проблема, не понял? Да, есть, да, входит... Где противоречие-то?

Спасибо за пояснения

В QtOpenGL есть ещё и классы для рендеринга в текстуру(и чтерез FBO, и чтерез PBuffer), которые наверняка используються для реализации OpenVG, но, наколько я помню, они сделаны правильно и быстро :-)

это хорошо, что такую штучку сделали :-)

> Грубо говоря - я не уверен, что плюсовая программа, использующая QtOpenGL, вызывает непосредственно glBegin - а не какой-нибудь метод какого-то класса, который вглубине себя вызывает glBegin. Вы можете ответить на этот вопрос пожалуйста?

Оверхед кстати получается копеечный. Если метод в котором спрятан пресловутый glBegin не виртуальный, как бы глубоко он не лежал по ирерархии, то он будет все равно вызываться напрямую, его инлайн сделать даже можно. Если втртуальный но не переопределенный потомками - то будет вызываться по косвенной ссылке, но все равно без продирания через толпу наследников, потому-что ссылка на метод будет храниться в VMT/DMT обьекта/класса при его создании. А если метод был переопределен то хоть на ООП хоть процедурно там кода по пояс накодерасено.