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 ()

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

>Единственное не имеющее в гноме аналогов приложение - K3B.

Ну вам, виндузятникам, не знающим, что такое интеграция и стабильность, всё равно что юзать

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

Да..... итересно, ты знаешь, что такое copy rigth ?

Назови ХОТЬ ОДНО серёзное(это твоё слово) коммерческое приложение на GTK...!!!

На Qt их достаточно... но это(в основном) не ширпотреб, поэтому не сильно известны

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

>но серьезных приложний нет, работать - нельзя.

А какие же "серьезные" приложения есть в гноме? Интересно узнать.

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

>серьезных приложний нет, работать - нельзя.

И с чем же вы работаете под гномом?

ptarh ★★★★★
()
Ответ на: комментарий от no-dashi

> Ну-ну, как назвать человека, пишущего вот такой код для прорисовки каждого фрейма?

А я, между прочим, явно написал: "были предприняты усилия, чтобы поставить библиотеки в равные условия". То, чего не написал, выглядит так:

"All tests go through the whole pipeline, meaning I tried to make sure that the framework doesn't cache too much and actually renders what's being asked."

"Все тесты проходят от начала до конца создания изображения, чтобы не кешировались данные между проходами".

Если не понятно: рисуется _одна_ картинка, от начала до конца. Работа повторяется в цикле. В результате замеряется фактическое время на один проход. Это не анимация, а бенчмарк тесселяции и рендера конкретного полигона, /без/ кеширования нарисованных ранее.

Сомневающиеся могут посмотреть код qtrender:

QPainter p(this);
p.setRenderHint(QPainter::Antialiasing);
p.setPen(Qt::NoPen);
p.setBrush(QColor(0, 0, 255));
p.drawPath(path);


-- на каждую итерацию создаётся новый QPainter, по окончании освобождается.

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

вот потому жабка со своими jcp стандартами и разнообразием JVMов и библиотек рулит не по децки.

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

>Поэтому программы серьезные, коммерческого уровня - появляются на gtk

Дядя - это ты про неру? Это которая на gtk 1.2.x - даже не на 2.x.x... сел попой в лужу... Или к примеру Opera - очень серьезное коммерческое приложение, написано на КуТе.

P.S. То-то на гтк уже полдюжины поделок имитирующих с разной степенью функциональность КДЕшный Amarok. А серьезных приложений для KDE тонны, открой для себя www.kde-apps.org, на крайняк можно запускать и ГТК программы, да так что по внешнему виду они будут не особо выделятся из основной массы.

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

> И что это доказывает? Реально куте и производные работают ТОЛЬКО на себя. Никакой пользы другим десктопам от них нет (я не говорю про пользователей, я говорю про совместное использование кода).

Странный вы человек, Корейко. Вам дают код под самой правильной и свободной лицензией - GPL. И всё равно вам не нравится. Ну не понимаю я вас, честное слово!

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

А зачем вам? Код закрывать и продавать? Неееет. Код должен оставаться свободным. Жуликам - бой.

> Потрясающий апломб! Весь fd.o & g.o - зоопарк отсталых технологий.

Бенчиарки показывают, что да. У вас есть другие тесты с другими результатами?

> ЗЫ Кстати, еще одна технология "от гнома ко всем" - мой libxklavier, который будет использоваться в kde4 (опционально IIRC). И он зависит (о ужас) от glib. И КДЕ согласились с этим. Политика NIH закономерно приводит к тому, что предоставленный кому угодно на мягких лицензионных условиях код "с корнями в мире g" таки проделывает лазейки в мир К. Обратное - неверное. Почему - указано выше.

А я так и не понял. Так кто вам мешает взять код из Qt. Несвободная лицензия GPL?

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

> Близорукость? Не замечать, сколько стандартов fd.o УЖЕ приняты в KDE.

Вот KDEшники открыты для всего мира и не брезгуют использовать лучшее, чтобы пользователям было удобнее. А гномеры отгородились от всех своим HIG'ом и бубнят злобно, как бобры под корягой.

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

>А я так и не понял. Так кто вам мешает взять код из Qt. Несвободная лицензия GPL?

Я тоже ржу над этим единственным и бестолковым аргументом GTK'шников - они явно шпионы MS)))

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

Разница есть - в qt данные вначале загоняются в path, а потом в цикле этот path заполняется и лениво рисуется ( QTimer::singleShot(0, this, SLOT(update()));). В cairo данные загоняют в path в каждом цикле и отрисовается он по вызову cairo_fill(cr) - т.е. сразу. Как-то сомнительно это все выглядит. Становится понятно, почему рендеринг в QT такой якобы шустрый. Хотя с тесселятором cairo, возможно, действительно лажает.

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

> Есть желание, чтобы приложения из разных миров могли сосуществовать (у пользователей, у 3rd party developers). Над этим и работает fd.o. И часто код, который может быть полезным не только в рамках гнома - переносится из g.o во fd.o. И часть этого кода УЖЕ используется в КДЕ. Вот такой вот односторонний обмен. Что, разумеется, ни капельки не делает кдешников моральными должниками коммюнити.

Хватать бубнить на всех. Код KDE доступен под самой правильной лицензией - GPL. Или ты Ричарда Матвеича не уважаешь?

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

И вопрос к тестеру - как у него glitz собран? (ldd, типа, давай) Может он с софтовой версией мезы слинкован, вот он и не дает ускорения по сравнению с XRender.

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

> Не нравится в qt то, что кодинг выливается в перекладывание кубиков аля басик.

Негде поипацца? Негде очередной buffer overflow вставить, да? Скукотища, понимаю.

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

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

> Если честно, я не понимаю, ЗАЧЕМ Троллям линуксы-шмынуксы виндовсы всаякие... ВОзникло впечатления, что совсем чуть-чуть - и QT будет самодостаточной кросс-архитектурной ПЛАТФОРМОЙ, не нуждающейся в ущербных прослойках, написанных на Си в квадратном корне %)

Не переживай, GNOME движется в том же направлении, только спотыкаясь, падая и непрерывно матерясь.

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

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

Ты не поверишь - им GPL мешает :) svu уже весь на гуано изошёл - и именно по этой причине :)

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

ох ведь.. кажется всего-то какой-то десяток лет назад холивары добрее были, что ли..

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

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

Так чё, лицензия GPL - самая несвободная, как оказалось? Какие ты тут ужасы живописуешь.

> Естественно ни один серьезный разработчик не пожелает сразу же терять право на свой код - поэтому кроме набора утилиток KDE под Qt ничего и нет.

Ой чучелко... SIM, licq, Opera, Scribus... Ни о чём не говорит?

Фсат, плакальщик. Писать коммерческий софт под финдафс.

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

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

Тролли не дают ему код закрывать, вот он и развонялся. Обычный проприентарный кодер, припёрся обиды свои поизливать.

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

>А инженерное решение в виде платформообразующих библиотек на плюсах (да еще плюсах в квадрате) меня никогда не будет нравиться, извините.

Почему?

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

>Вообще-то для тестов правильно измерять И ТО И ТО, правда?;)

Не вижу смысла измерять производительность без нагрузки. Без нагрузки работает. А если машинка будет слабая? А если понадобится вывести больше, чем в среднем? И что мы тогда будем делать? Смотреть, как тормозит замечательная кайро? Или не заметим ничего на qt?

Как конечному пользователю наверное мне понравится некий запас мощности?

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

>И все-таки АтроОфирует;)

То-то я смотрю, что что-то не смотрится... ;))))

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

>А в чём тогда смысл вышеобозначенного теста с использованием Qt и Cairo для динамичной трёхмерной графики?

Что ты слышал об аппаратном ускорении графики для рабочих столов, трехмерных рабочих столах и "векторных" значках?

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

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

Уже обсуждали. Потребление памяти такое же, скорость выше.

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

>То что писано под QT 3.0.0 - заработает (я уж молчу про "скомпилится без костылей"), если подсунуть, скажем, QT-3.3.7?

sim, собранный под fc3 (версии 0.9.3) заработал под fc5 с обновлениями. Причем 32-битной сборки на x86_64 (в режиме совместимости). И ничего - я месяц на нем просидел.

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

>Суть проблемы в том, что ты сразу должен решить GPL ли твой код - и если ты начал писать программу под GPL Qt ты лишаешься права

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

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

А мы с Syncro дебилы с альтернативным видением интерфейса, да? Который год в KDE сидим и работаем. На gnome не тянет.

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

> Разница есть - в qt данные вначале загоняются в path, а потом в цикле этот path заполняется

Я тебе открою маленькую тайну: внутри drawPath() содержится цикл, который выполняет moveTo(), lineTo() и так далее -- аналог cairo_append_path() + cairo_fill() в одном флаконе. Промежуточный код с преобразованием данных в QPainterPath нужен только для того, чтобы скармливать drawPath ожидаемые им объекты -- это просто часть парсера файла данных.

> и лениво рисуется ( QTimer::singleShot(0, this, SLOT(update()));).

В Qt никогда ничего не рисуется просто так, пока виджету не придет update. В данном случае этот сигнал просто приводит к повторному вызову paintEvent(). То-есть это не "ленивое" рисование, а просто рекурсия на самого себя через сигналы. Цикл так реализован.

> В cairo данные загоняют в path в каждом цикле и отрисовается он по вызову cairo_fill(cr) - т.е. сразу.

В Cairo нет механизма создания cairo_path отдельно, или его переноса из одного cairo_t* в другой, кроме cairo_copy_path() + cairo_append_path(). Загляни на досуге в реализацию последней функции -- увидишь тот же самый цикл cairo_move_to(), cairo_line_to() и т.д. В draw_poly() даже быстрее сделано. По сути, реализован аналог drawPath(), то есть сейчас qtrender и cairorender по набору выполняемых операций практически эквивалентны.

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

> хоронят xmms не из-за gtk, а из-за того что xmms мёртвый проект.

Хоронят его как раз из-за GTK, но не потому, что он GTK, а потому, что он GTK1.

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

> Назови ХОТЬ ОДНО серёзное(это твоё слово) коммерческое приложение на GTK...!!!

VMWare. NeroLinux.

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

> Единственное не имеющее в гноме аналогов приложение - K3B.

graveman (фактически тот-же gui под dvd+rw-tools/cdrecord) плюс встроенная в файловый менеджер GNOME/XFCE писалка = K3B. Про размеры K3B думаю не стоит и говорить - более 22MB

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

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

Но тест на туеву кучу тысяч вершин как-то не тянет на desktop. Или я не прав?

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

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

AFAIU функциональность glib где-то в районе половины от QtCore? да, последний несомненно на порядок больше тонюсенького glib...

$ ls -l /usr/pkg/qt4/lib/libQtCore*
-r-xr-xr-x 1 foo foo 1613756 Oct 24 11:54 /usr/pkg/qt4/lib/libQtCore.so.4.1.4

$ ls -l /usr/pkg/lib/libglib*
-rwxr-xr-x 1 foo foo 653405 Jul 26 15:11 /usr/pkg/lib/libglib-2.0.so.0.1200.1

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

как минимум, обратное то-же вполне справедливо: в gnome нет ничего, что бы отсутствовало в kde и, отчасти, qt. тогда напрашиваеться вполне резонный вопрос: а нахрена нужен гном, дублирующий kde? велосипедостроительство чистой воды. еще какой-то freedesktop приперся. "кто все эти люди и что им нужно"? если есть KDE и Qt.

// wbr

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

> Под зонтиком у "какого-то" freedesktop-а живут:
http://xorg.freedesktop.org/wiki/
http://freedesktop.org/wiki/Software_2ffontconfig
http://dri.freedesktop.org/wiki/

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

// wbr

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

>>graveman (фактически тот-же gui под dvd+rw-tools/cdrecord) плюс встроенная в файловый менеджер GNOME/XFCE писалка = K3B. Про размеры K3B думаю не стоит и говорить - более 22MB
Ну, встроить прожиг в конк труда не составит есть kio-burn. А насчет веса k3b - 22M ето наверное с дебагом собранное ;-)

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

Спрашивал же "кто все эти люди и что им нужно"? По-моему, вышеперечисленного достаточно, чтоб понять, кто эти люди, и что ссориться с ними не стоит, поскольку живут они на один уровень абстракци ниже, чем всякие там QT и GTK.

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

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

Opera, GoogleEarth, Skype?

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

Скорее он в распакованном виде столько весил, когда я его удалял. Я про то что уникальность K3B надуманная.

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

> Спрашивал же "кто все эти люди и что им нужно"? По-моему, вышеперечисленного достаточно, чтоб понять, кто эти люди, и что ссориться с ними не стоит, поскольку живут они на один уровень абстракци ниже, чем всякие там QT и GTK.

при желании, Qt можно пустить хоть через fb, что впрочем и применяется в определенных кругах. да и зачем, собственно, с кем-то именно ссориться? это ведь ничего не дает. можно просто радостно соглашаться и молча игнорировать. есть очередная инициатива XYZ? прекрасно! просто отлично. ну и хрен с ней. бо у нас, возможно, свой собственный roadmap.

ps: мне почему-то до сих пор казалось, что Xorg все-же живет на www.x.org. равно как их их вики, списки рассылки etc. а ссориться или сильно дружить с ребятами из DRI.. а зачем? на фоне закрытых драйверов от нехороших вендоров эт конечно оч актуально :) дружить нужно с nVidia, а не с DRI.

// wbr

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

>graveman (фактически тот-же gui под dvd+rw-tools/cdrecord) плюс встроенная в файловый менеджер GNOME/XFCE писалка = K3B. Про размеры K3B думаю не стоит и говорить - более 22MB

Во первых пора бы уже наконец сдать в металлолом свой гигабайтный винчестер и перестать скулить про размер в 22 Мб. Во вторых, этот грейвман создавать Audio-cd, DVD-Video и т.п. умеет? И в третьих, не пробовал собирать К3В только с тем функционалом который тебе необходим, тогда он занимает гораздо меньше места.

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

>>при желании, Qt можно пустить хоть через fb

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

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

> Разве кто-то сомневался (что Qt на голову выше других библиотек)?

Был тут один юморист с именем geek. Запил, наверное, с горя, когда осознал что его фетиш с жизнью имеет мало общего. :)

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

> Был тут один юморист с именем geek. Запил, наверное, с горя, когда осознал что его фетиш с жизнью имеет мало общего. :)

фетиш - это скорее психологическая зависимость и настоящие фетешисты на такие мелочи внимания не обращают ;)

// wbr

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

> Кол-во функциональности, реализованной в qt - на порядок больше - но совсем не потому, что gtk "ниасилил". Просто разные подходы. Сравнивать бессмысленно.

Как раз смысл есть. Мне нужно консистентую библиотеку, а не базовый набор + куча кривых сторонних поделок. :(

> Надеюсь, Вы не строите Ваши умозаключения на основе одного скромного и слегка сомнительного бенчмарка?

Фишка в том, что GTKшники и таких бенчмарков не выдают. Только жалкие опусы, горячо обсуждаемые в соседнем топике. :)

> Да, пожалуй. Наверняка от необходимости программировать на плюсах - пострадает гораздо больше;)

А что, количество фанатичных программистов на C хотя бы сопоставимо с количеством программистов на C++? :)

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

> gtk - это только тулкит. А qt - это "раскладной стульчик, он же зонтик". Кол-во функциональности, реализованной в qt - на порядок больше - но совсем не потому, что gtk "ниасилил". Просто разные подходы. Сравнивать бессмысленно.


libgtk - 3 635 785
libglib - 663 547
libgobject - 281 447
итого - 4 580 779

QtCore - 1 171 456
QtGui - 4 333 568
итого - 5 505 024

Qt больше на 20 % - но на порядок более функциональна
и в добавок еще и быстрее
внимание вопрос - нахрена использовать _ГАВНО_ ?


>> От невозможности программировать с qt на C я думаю пострадает очень незначительная часть программистов.

> Да, пожалуй. Наверняка от необходимости программировать на плюсах - пострадает гораздо больше;)

дебилов использующих С надо убивать - очищать генофонд

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

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

KDEшники всеядны. GNOMовцы - фанатичны. И с их C не получится использовать код KDE. :)

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

просмотрел зависимости - еще один жирный минус gtk

libgtk - 3 635 785
libglib - 663 547
libgobject - 281 447
libgdk - 1 000 445
libatk - 138 241
libpango - 271 524
итого - 5 990 989

QtCore - 1 171 456
QtGui - 4 333 568
итого - 5 505 024

Qt меньше !!!! и функциональнее !!!!
к черту gtk !!!!!!!!

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

> поэтому кроме набора утилиток KDE под Qt ничего и нет.

Ну да, Google Earth - мелкая утилитка. :)

> Поэтому программы серьезные, коммерческого уровня - появляются на gtk

Nero и Acrobat Reader - очень серьёзные приложения, ага. Не смешите людей. :)

> Пользовал я KDE - да, красиво, удобно - но серьезных приложний нет, работать - нельзя.

Назовите критерии "серъёзности" приложения.

> Единственное не имеющее в гноме аналогов приложение - K3B.

Чем gnomebaker не устраивает? :)

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