LINUX.ORG.RU

Открытая реализация OpenVG


0

0

Зак Расин (Zack Rusin) сделал первую свободную реализацию OpenVG -- кроссплатформенного API, предоставляющего низкоуровневый интерфейс к аппаратному ускорению отрисовки векторной графики. Его реализация основана на QtOpenGL (Qt 4.3) и уже сейчас достаточно полноценна, хотя некоторые важные функции вроде текстур пока не реализованы. По ссылке "Подробности" можно узнать, как получить актуальный срез git.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

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

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

LestorN
()
Ответ на: В догонку от sS

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

svu ★★★★★
()
Ответ на: В догонку от sS

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

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

LestorN
()
Ответ на: комментарий от svu

>Да плюсисты любой интерйфейс через .... 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

adarovsky ★★★★
()
Ответ на: комментарий от svu

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

AP ★★★★★
() автор топика
Ответ на: комментарий от LestorN

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

svu ★★★★★
()
Ответ на: комментарий от adarovsky

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

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

adarovsky ★★★★
()
Ответ на: комментарий от svu

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

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

vtVitus ★★★★★
()
Ответ на: комментарий от svu

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

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

baka-kun ★★★★★
()
Ответ на: комментарий от svu

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

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

e_val ★★★
()
Ответ на: комментарий от vadiml

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

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

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

e_val ★★★
()
Ответ на: комментарий от adarovsky

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

svu ★★★★★
()
Ответ на: комментарий от e_val

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

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

svu ★★★★★
()
Ответ на: комментарий от LestorN

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

Linfan ★★★★★
()
Ответ на: комментарий от Led

>Нет

Да

"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."

geek ★★★
()
Ответ на: комментарий от svu

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

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

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

e_val ★★★
()
Ответ на: комментарий от AP

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

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

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

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

Linfan ★★★★★
()
Ответ на: комментарий от svu

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

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

e_val ★★★
()
Ответ на: комментарий от geek

> "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шным.

e_val ★★★
()
Ответ на: комментарий от svu

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

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

e_val ★★★
()
Ответ на: комментарий от e_val

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

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

AsphyX ★★★
()
Ответ на: комментарий от AsphyX

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

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

e_val ★★★
()
Ответ на: комментарий от svu

> Ок, тогда, возможно, я неточно представляю роль 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.''

baka-kun ★★★★★
()
Ответ на: комментарий от svu

> freeglut?

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

e_val ★★★
()
Ответ на: комментарий от e_val

>> freeglut?

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

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

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

anonymous
()
Ответ на: комментарий от svu

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

svu ★★★★★
()
Ответ на: комментарий от anonymous

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

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

e_val ★★★
()

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

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

azazello ★★★★
()
Ответ на: комментарий от azazello

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.