LINUX.ORG.RU

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


0

0

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

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

★★★★★

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

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

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

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

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

Re: В догонку

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

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

Re: В догонку

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

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

Re: В догонку

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

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

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

Re: В догонку

>Да плюсисты любой интерйфейс через .... 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 ★★★★ ()
Ответ на: Re: В догонку от svu

Re: В догонку

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

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

Re: В догонку

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

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

Re: В догонку

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

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

Re: В догонку

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

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

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

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

Re: В догонку

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

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

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

Re: В догонку

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

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

baka-kun ★★★★★ ()

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

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

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

petrosha ★★★★★ ()

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

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

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

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

Re: В догонку

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

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

e_val ★★★ ()
Ответ на: Re: Открытая реализация OpenVG от vadiml

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

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

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

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

e_val ★★★ ()
Ответ на: Re: В догонку от adarovsky

Re: В догонку

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

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

Re: В догонку

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

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

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

Re: В догонку

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

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

Re: В догонку

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

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

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

e_val ★★★ ()
Ответ на: Re: В догонку от AP

Re: В догонку

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

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

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

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

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

Re: В догонку

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

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

e_val ★★★ ()
Ответ на: Re: Открытая реализация OpenVG от geek

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

> "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 ★★★ ()
Ответ на: Re: В догонку от svu

Re: В догонку

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

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

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

Re: В догонку

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

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

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

Re: В догонку

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

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

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

Re: В догонку

> Ок, тогда, возможно, я неточно представляю роль 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 ★★★★★ ()
Ответ на: Re: В догонку от svu

Re: В догонку

> freeglut?

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

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

Re: В догонку

>> freeglut?

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

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

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

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

Re: В догонку

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

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

anonymous ()
Ответ на: Re: В догонку от anonymous

Re: В догонку

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

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

Re: В догонку

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

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

e_val ★★★ ()

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

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

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

azazello ★★★ ()
Ответ на: Re: Открытая реализация OpenVG от azazello

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

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

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

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