Скорость отрисовки в Qt - где быстрее?

Где ваши доказательства?

надо узнавать какое hardware acceleration  задействовано в разных 
случаях. 

Доказательства - только то что получилось на моем компьютере (ноутбук samsung q210, Intel Core 2 Duo). Кстати проверял и на обычном десктопе (atlon 64)- результат тот же. Если у кого-то другие результаты - сообщите. Мне интересно разобраться в чем причина.

Проверялась обычная графика (не OpenGL)

> Проверялась обычная графика 

имеется ввиду задействованы ли X extensions 

Привожу выдержку из xorg.conf: Section "Module" Load "dbe" Load "dri" Load "glx" Load "extmod" Load "xtrap" Load "record" EndSection

Section "Device" ### Available Driver options are:- ### Values: <i>: integer, <f>: float, <bool>: "True"/"False", ### <string>: "String", <freq>: "<f> Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [<bool>] #Option "NoAccel" "True" # [<bool>] #Option "SWcursor" "True" # [<bool>] #Option "ColorKey" # <i> #Option "CacheLines" # <i> #Option "Dac6Bit" "True" # [<bool>] #Option "Dac6Bit" # [<bool>] #Option "DRI" # [<bool>] Option "DRI" "True" # [<bool>] #Option "NoDDC" "True" # [<bool>] #Option "ShowCache" "True" # [<bool>] #Option "ShowCache" # [<bool>] #Option "XvMCSurfaces" # <i> #Option "PageFlip" # [<bool>] #Option "PageFlip" "True" # [<bool>] Identifier "Card0" Driver "intel" #Driver "vga" VendorName "Intel Corporation" BoardName "Unknown Board" BusID "PCI:0:2:0" EndSection

Но разве может быть в этом проблема - ведь эмуляторы используют ту же видеокарту и тот же Xorg? Тесты запускались одновременно из под одной линуксы - но в эмуляторах скорость отрисовки быстрее!

GDI+ быстрее рисует картинку, чем иксовые библиотеки, через которые рисуют линуксовые тулкиты. Вот и все дела, забей. Или напиши патч.

И ничего нельзя сделать (скажем покапаться в настройках Xorg или скомпилить с особой оптимизацией)?

> эмуляторах скорость отрисовки быстрее

возможно - это внутреннее свойство самого Qtшного кода.
когда-то разбирался с исходниками Qt paintera,  как под Xми, 
так и под win32. конечно код там "разный" , и возможно , 
самый нижний уровень написан более оптимально для windows
(типа, больше всякого локального кэширования).

конечно, инересно разобраться зависит ли это карты,
ну если эмуляторы "лучше распознают" имеющиеся
возможности карты. 

Вопрос интерсный - его ожно поднять на qt-develop liste

http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/

>http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/


ссылка, конечно, интересная.
Но, проблема состоит в том, что эмуляторы (wine, virtual box), 
в конце концов вызывают Xвые методы для отрисовки и bitblt
(если отсутствует gl)

А что тут ещё можно сделать? Если одна библиотека быстрая, а другая медленная, то без разницы, что там сверху на них положат. Единственный путь - оптимизация xrandr.

> Но, проблема состоит в том, что эмуляторы (wine, virtual box), в конце концов вызывают Xвые методы для отрисовки и bitblt (если отсутствует gl)

[далее идёт мнение дилетанта, так что можете мне не верить, а лучше меня поправить если я где-то не прав]

Есть мнение, что и wine и virtualbox рисуют графику через область разделяемой памяти. Т.е. они запрашивают у сервера область памяти с битмапом, который отображается в конкретном окне. Если сильно повезёт - то это вообще будет кусок памяти видеокарты, отображённый в адресное пространство процесса. А в случае если запускать программу нативно, то отрисовка в целях совместимости будет происходить путём перегона картинок через unix-сокет* иксов. Это конечно хорошо, если клиент и сервер на разных машинах, но зачем делать это всегда, с учётом того, что нужно это 0,0000000000000000000001% пользователей - загадка.

Медлительность иксовой графики вообще очень заметна и проблема это древняя. Для победы над этим изобрели несколько костылей (DRI для OpenGL и вон рисование через разделяемую память (не помню как точно расширение называется)), но что-то как-то не сильно помогло.

P.S. Я готов что сейчас понабежит куча народу и начнут кидать какашками и доказывать что бревна в глазу у них нет.

> Если одна библиотека быстрая, а другая медленная,

в обоих случаях использутся Xlib.
но, "там сверху" , Qt painter написан по разному для win32 и X11
реализаций. Потому что X - это client-server, а  win32 gdi - нет.

Например, что win32 painter кэширует ("локально") часто используемые
GDI brushes, pens, pixmaps etc. В Xах им соответствуют GCs, 
которые "располагаются на сервере". возможно qt-developers
посчитали, что  кэшировать локально их не  имеет смысла.
за счёт этого и "тормознее".
Это только моё предположение, причина может быть совсем другой.

++
самый большой тормоз в отрисовке, как известно, - bitblt.
скорее всего где-то wine/virtual box или win32 Qpaintere
он реализован более оптимально (типа, Xshm by default)
или  Xrender в одном случае задействован, а в другом нет

а смысл их кешировать локально?

У меня в линуксе также Qt (не через OpenGL) в два раза тормознее чем в винде рисует: http://trac-hg.assembla.com/jgears/wiki/ResultsHome#WithAntialiasingNoQtOpenG... Похоже, что дело в драйверах или в самих X-ах. Да и вообще все как-то тормозно в плане интерфейса в линуксе, до винды явно не дотягивает. И это на NVIDIA, которая типа хорошо поддерживается в линуксе...

Чисто субъективно Qt в Windows рисовалась нааамного быстрее чем в Linux.

+1

Я пытался сказать то же самое, но не получилось.

В X-ах ещё используется извратная система асинхронных сигналов отрисовки - к примеру, если отрисовывать 2D графику - вывести изображение, которое потом скроллить мышью (получить сообщение от мыши, пересчитать картинку и послать сигнал на отрисовку) - то мышиных сигналов придет огромное количество, чего нету в винде и макоси; если рисовать к примеру с OpenGL в QT - то отрисовка не отложенная будет, а по запросу - в противоположность этому с GLUT будут такие же тормоза. Можно конечно исправить ситуацию, по крайней мере с QT - использовать один небезопасный флаг, если раотать с X11.

Скорее всего, нечто происходит и с отрисовкой стандартных виджетов - ты нажал на кнопку, а когда она перересуется - как X-сервер решит.

сам GDI API  "более продвинутый" , чем Xы -
все эти, Begin/End paintы , "dirty regions" etc.
ваааще,  чё там всеэти "кэйты пакарды" делают?
где компрессия? где, хотя бы, то что давноесть в mpeg4