LINUX.ORG.RU

Сравнение производительности Qt и Cairo


2

0

Зак Русин провел сравнение производительности векторной графики в Qt и Cairo. Тест состоит из рендеринга трех сложных полигонов: text path, маленький полигон с большим количеством вершин на одной линии, огромный полигон с количеством вершин порядка 100000.

Измерялось количество кадров в секунду, использовались версии Cairo 1.2.5 (XRender и Glitz), Amanith из svn, Qt 4.3 (XRender и OpenGL) на Pentium4 3.2ГГц, 1Гб, NVIDIA 6600 с драйвером 1.0-9625.

Все тесты использовали антиалиасинг, и были предприняты усилия, чтобы поставить библиотеки в равные условия. Результаты очень интересны:

* Qt быстрее Cairo в XRender в 5-7 раз
* Qt(OpenGL) быстрее Qt(XRender) в 5-7 раз, но упирается в производительность GPU при 80000+ вершин
* Cairo(Glitz) показывает одинаковую производительность с Cairo(XRender)
* Ни Amanith, ни Cairo(XRender) не могут справится с последним полигоном в 100000 вершин.
* С большим полигоном Cairo(Glitz) отображает 0.2 кадра в секунду, а Qt переваливает за 10 fps.
* Qt(XRender) на порядок превосходит по производительности и Cairo(Glitz), и Amanith, хотя последние работают с OpenGL ускорением, а первый без него.


Выводы: Qt на голову выше других библиотек, а в OpenGL настолько быстр, что сравнивать с чем либо ещё просто нечестно.


PS от автора новости: Остается надеяться, что OpenSource позволит авторам Cairo "подсмотреть" построение тесселятора и рендерера, чтобы сократить разрыв до приемлемых значений.

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

★★★★★

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

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

> И часть этого кода УЖЕ используется в КДЕ. Вот такой вот односторонний обмен. Что, разумеется, ни капельки не делает кдешников моральными должниками коммюнити.

И шо, таки прям ни строчки кода кедостроители в fdo не закоммитили? Что-то не верится. Тот же Portland, IIRC, не одни гномовцы строили.

Не говоря уже о том, что они участвуют в разработке fd.o стандартов активно (тот же dbus очень много чего взял от DCOP), и самостоятельно их реализуют. Ты же не будешь отрицать, что наличие _нескольких_ реализаций - это хорошо для стандарта?

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

gstreamer из amarok'а выкинули (почти) после очередной поломки API первого, а вы говорите стандарты ..

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

> Кто-то запрещает переносить код из кед в гном?

Лицензия GPL.

> Если уж в кедах будет зависимость на glib, то почему в гноме не может быть зависимости на kdelibs/qt?

Потому что:

1. Зависимость на ТОЛСТЕННЫЙ qt никто в гноме не потерпит (см. размер libglib.so)

2. Потому что нет в qt ничего, чего бы не было в гноме или в fd.o - в каком-то виде.

Дело не в переносе kde->gnome. Дело в переносе Kde->fd.o. Это должен быть общий код, не зависящий от базового тулкита и (по возможности) от конкретной объектной модели.

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

> однако dbus скорее интегрирован в Линукс (как дистрибутив) чем в КДЕ.

Гхм. Вообще-то, он вроде как кросс-платформенный. Но я не о том. Корни его - в гноме, исторически.

Про монолитный подход Qt даже спорить не буду. Его и так уже разбили на разные библиотеки, так что разница в подходах постепенно исчезает.

> Когда предлагаемый "стандарт" не подходит

Извините, но некоторое время назад каиро просто не могло подходить или не подходить (его не существовало) - кто мешал кутешникам активно подключиться и сделать совместно одну библиотеку, пригодную для всех платформ?

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

> Дело в переносе Kde->fd.o. Это должен быть общий код, не зависящий от базового тулкита и (по возможности) от конкретной объектной модели.

в любом случае kde, xfce разработчикам придется делать обертки для этого кода, учитывая то, что за ними придется следить активнее чем за собственными NIH решениями (из за постоянной ломки API и плохой документированности как я уже постил выше), такая ситуация выглядит выгодной только для gtk(на С) и как реализации в десктопе gnome разработчиков.

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

Кдешники безусловно коммитят в fd.o. За что им всяческий решпект. Но я ж не про это - я про целые проекты, которые вегетативным методом могут отпочковываться от базового стека и становиться стек-независимыми. Что мы наблюдаем только с одной стороны.

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

> Дело не в переносе kde->gnome. Дело в переносе Kde->fd.o. Это должен быть общий код, не зависящий от базового тулкита и (по возможности) от конкретной объектной модели.

Имхо, не дело fd.o код писать, в общем-то. Понятно, что если они перестанут это делать - то превратятся в еще один никому не нужный w3c.org - но тем не менее. Стандарт издали, reference есть? Хорошо. А то, что кто-то пишет все то же самое заново - так это даже правильно, дырок в стандарте найдут больше...

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

> кто мешал кутешникам активно подключиться и сделать совместно одну библиотеку, пригодную для всех платформ?

ох, еслиб у бабки были яйца ... ну они и сделали одну библиотеку пригодную для всех платформ;)

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

> учитывая то, что за ними придется следить активнее

Вы осознаете, что только что выдали классическую и главную отмазку для NIH-а?

> такая ситуация выглядит выгодной только для gtk(на С)

Вот в этом разница! Вы видите десктоп как одеяло, которое надо тянуть на себя (см. рассуждения про "кому выгодно"). Гном видит как обще-линуховую проблему, частным случаем решения которой является гном. Именно поэтому гному не западло отдавать код и делать его не завязанным на стек - потому что решение проблемы десктопа является общей задачей.

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

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

это все тлетворное влияние C++: не разводить бардак повторяющегося функционала, а наследовать существующее, переопределяя необходимые свойства:)

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

Возражение про reference implementation принято. Беда в том, что в случае с каиро стандартизация идет от кода (что нездорово, конечно же). Удалось бы вылизать код, потом принять стандарт - а потом пусть реализуют кто во что горазд.

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

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

гном отдает свой неэффективный код под стандарт навязывая свое решение остальным. Чем не политика M$ ? и постоянная ломка API оттуда же

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

Тоже не понимаю бурчания в адрес Qt, отличный фреймворк, с которым можно работать.
Конечно гонка за технологиями сказывается, не мешало бы над оптимизацией поработать, ну и мелочей маловато.  Ну пеняют еще на препроцессор (поклонники языка)

Все! Все остальное сделано на ура. + лицензия позволяет работать.
Весь остальной гон, явное пионерие.

daaaad
()

Очередные фирменные иллюзии от троллей. Назовите мне для начала несколько красивых и быстрых 3D-игрушек которые написаны на Qt или Cairo.

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

> стандарт навязывая свое решение остальным. Чем не политика M$ ?

Вы действительно не видите разницы? Процесс стандартизации на fd.o - открытый. Голос КДЕ, когда он раздается - учитывается. Кто кому что навязывает? КДЕ были навязаны hal/dbus/pkgconfig/... ?

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

> я про целые проекты, которые вегетативным методом могут отпочковываться от базового стека и становиться стек-независимыми

fork
[fɔ:k]

...

4> разветвление; ответвление

тут люди xmms хоронят, из-за gtk

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

>гном отдает свой неэффективный код под стандарт навязывая свое решение остальным.

Гном то отдает - пусть неэффективный, а жадные троллтеки свои мега-эффективные решения ПРОДАЮТ. Разница ферштеен?

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

>А я хочу LGPL/Apache/BSD/X11. Можно?

А гном держит эти лицензии? Не знал, не знал.

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

какой еще голос ?

общая хронология процесса:

1) из гнома выделяется "стандарт" т.е. библиотека готовая к применению только в гноме/gtk проектах

2) на нее очень долго никто не обращает внимания

3) через какое-то время создаются враперы остальными заинтересованными

4) ее в очередной версии ломают, она становится пригодной для работы только с новейшим гномом (организованно ломают ить, где голоса не гномовцев ?) история продолжается с п. 2

еще один пример xgl/aiglx/compiz/beryl. С такой методологией бардак будет всегда. И зачем понадобился aiglx и beryl, если в нашем королевстве такие замечательные стандарты ?

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

Предмет разговора пуст изначально - у KDE и GNOME различные подходы к решению задач.

los_nikos ★★★★★
()
Ответ на: комментарий от Qui-Gon

отдается под GPL без иных ограничений. Так же как и linux-kernel

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

тогда бы хоронили не в одночасье. Выкидывают gtk1 - выкидывают xmms. Так получилось, что переезд на gtk2 стал возможен только после форка (двойного ?) об чем и толкую

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

Ланн, до завтрашнего вечера всем. Have to hit the fscking road...

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

> И часть этого кода УЖЕ используется в КДЕ. Вот такой вот односторонний обмен. Что, разумеется, ни капельки не делает кдешников моральными должниками коммюнити.

> А тролтех, конечно, никому ничего не должен. Он только бабло должен зарабатывать, чтоб инвесторы были счастливы.

тут как-то пробегало, что тролли что-то в иксах правили для ускорения работы -- свой код из qt в иксы перенесли (как раз в стороне апп.ускорения)

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

ну не dbus так hal, это вписывается в сказку о совместном использовании кода ?

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

> ага, давайте делать "QtOs"!

а кто дрова будет писать?

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

>Очередные фирменные иллюзии от троллей. Назовите мне для начала несколько красивых и быстрых 3D-игрушек которые написаны на Qt или Cairo.

Гм. А разве их не на SLD и OpenGL пишут?

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

>> Кто-то запрещает переносить код из кед в гном?

> Лицензия GPL.

<mihalych_mode>

Самая кошерная лицензия мешает? Или ты предлагаешь пахать на проприетарщиков, а не на сообщество?

</mihalych_mode> :D

Это, конечно, шутка юмора, но никто не заставляет совместные библиотеки лицензировать под GPL. Посмотри на KDE, например -- стараются всё писать под LGPL. И, как тебе прекрасно известно, активно участвуют в fd.o.

> 1. Зависимость на ТОЛСТЕННЫЙ qt никто в гноме не потерпит (см. размер libglib.so)

Давай посмотрим: менее полутора мегабайт -- libQtCore.so, примерно 700к -- libglib.so. Разделяемая библиотека, в памяти /одна/ копия. Да, QtCore в целых два раза больше, но вот по количеству полезных вещей разница много больше, и не в пользу glib.

> 2. Потому что нет в qt ничего, чего бы не было в гноме или в fd.o - в каком-то виде.

В том-то и беда -- "в каком-то виде"... Как минимум, своей векторной библиотеки нет (хорошей). А с аналогом QtSql как? Нативная поддержка Win/Mac, с родным look-n-feel? Свой xhtm/dom/ecma-script framework? Подробная докуменация? Этого всего либо нет, либо "в каком-то виде", а ведь вещи повседневной необходимости.

> Дело в переносе Kde->fd.o. Это должен быть общий код, не зависящий от базового тулкита

Проблемы с переносом LGPL кода KDE надуманы.

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

> это все тлетворное влияние C++: не разводить бардак повторяющегося функционала, а наследовать существующее, переопределяя необходимые свойства:)

О да, в результате через пяток-другой итераций получая дикое дублирование "наследуемым" кодом, слив памяти в никуда за просто так и требования уровня атлон-2Ггц под херовенький тетрис. В итоге функционал таки да повторяется, бардак возрастет нелинейно, и толку в результате - никакого.

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

> гном отдает свой неэффективный код под стандарт навязывая свое решение остальным. Чем не политика M$ ? и постоянная ломка API оттуда же

Какая ломка, дядя: gtk+-2.4.0 -> gtk+-2.10.6 без каких либо проблем, не говоря о базовой обвязке glib+atk+pango+cairo. То что писано под QT 3.0.0 - заработает (я уж молчу про "скомпилится без костылей"), если подсунуть, скажем, QT-3.3.7?

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

ты либо не очень умный либо троль.

Cairo это фреймворк для рендеринга 2D примитивов с антиалиасингом.

в Qt4 есть аналог такого фреймворка. у них есть бекэнды как для XRender та и для OpenGL (ОpenGl ускоряет 2д). Сравнивают их производительность на выполнении одинаковой задачи - собственно "рендеринга 2D примитивов с антиалиасингом". Где здесь речь шла про "Qt и Cairo для динамичной трёхмерной графики" или тем более про игры ?

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

> тут люди xmms хоронят, из-за gtk

Дык правильно, кому интересна закономерно заброшенная поделка незаметно выросших из возраста "пишем на коленке" раздолбаев, заточивших оную под либку 5-летней давности, которую не то что развивать - фиксить уже всем без исключения западло?

ГТК 1.2.10 без пачки апдейтов на современной системе банально не соберется, не говоря уже о багах и устаревших интерфейсов. Даже mp3-код - и тот ниасилили написать самостоятельно и сперли из mpg123, все без исключения прочее - тянется из внешних либок, нативно своего в XMMS разве что плагины визуализации и редкостно баянистый интерфейс (+ недокументированные падения при работе с плагином flac и потоками).

Ну и главный системный баг - неразделение на функционал (играющий демон с прозрачной работой по сети) и интерфейс к оному.

e
()
Ответ на: комментарий от Qui-Gon

>Гном то отдает - пусть неэффективный, а жадные троллтеки свои мега-эффективные решения ПРОДАЮТ. Разница ферштеен?

Ты дурачёк? Тролли, свои решения под GPL отдают, ни что не напоминает? ядро одной OS например?

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

> > Очередные фирменные иллюзии от троллей. Назовите мне для начала несколько красивых и быстрых 3D-игрушек которые написаны на Qt или Cairo.

> Гм. А разве их не на SLD и OpenGL пишут?

Поколение пепси. Остается возносить хвалу всем богам без исключения, за то что их шаловлиые ручки и беспокойный моск еще не добрались до Жабы с J-GL.

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

>Какая ломка, дядя: gtk+-2.4.0 -> gtk+-2.10.6 без каких либо проблем, не говоря о базовой обвязке glib+atk+pango+cairo. То что писано под QT 3.0.0 - заработает (я уж молчу про "скомпилится без костылей"), если подсунуть, скажем, QT-3.3.7?

Помнится, в толках проскакивала ссылка на блог разработчика Thunar, который так опечалился от очередной поломки в гтк, что даже предложил переехать на Qt, мотивируя как раз тем, что API более стабильное.

ЗЫ. В Assistant'е всегда есть раздел, про мигрирование на новую версию либы.

h8 ★★★
()
Ответ на: комментарий от Qui-Gon

>Гном то отдает - пусть неэффективный, а жадные троллтеки свои мега-эффективные решения ПРОДАЮТ. Разница ферштеен?

Блин, откуда ж я его взял, ничего не заплатив? Неужели украл?? о_О

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

Тролли отдают свое гумно под двойной лицензией, причем весьма жесткой.

Суть проблемы в том, что ты сразу должен решить GPL ли твой код - и если ты начал писать программу под GPL Qt ты лишаешься права на использование своего СОБСТВЕННОГО кода в своих коммерческих программах. Даже купив для этих программ коммерческую лцензию Qt. Естественно ни один серьезный разработчик не пожелает сразу же терять право на свой код - поэтому кроме набора утилиток KDE под Qt ничего и нет. Также как купив Qt за немалые деньги - разработчик врядли пожелает выпускать бесплатные версии. Поэтому программы серьезные, коммерческого уровня - появляются на gtk - и только потом лениво портируются на Qt силами любителей.

Пользовал я KDE - да, красиво, удобно - но серьезных приложний нет, работать - нельзя. Единственное не имеющее в гноме аналогов приложение - K3B.

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

Лично мне они отдают под одной лицензией - GPL и я вижу в ней только хорошее... если тебе они отдают под некой "двойной" лицезией, то опиши, что это такое?

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

>Суть проблемы в том, что ты сразу должен решить GPL ли твой код - и если ты начал писать программу под GPL Qt ты лишаешься права на использование своего СОБСТВЕННОГО кода в своих коммерческих программах.

Да пошли вы с такими взглядами... Почитайте "Just For Fun" и статьи Столмана/// там отлично написано, что каждый должен платить... в данном случае кодом. ТОЧКА!!! Поклонники MS идут лесом!!!

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