[Development] Proposal: Qt 4.9 release

Sven Anderson Sven.Anderson at snom.com
Thu Aug 16 10:21:24 CEST 2012


On 15.08.2012 21:35, Romain Pokrzywka wrote:
> On Wednesday, August 15, 2012 08:36:35 PM Thiago Macieira wrote:
>> On quarta-feira, 15 de agosto de 2012 22.05.02, Konstantin Tokarev wrote:
>>>  From wiki:
>>>
>>> "QPA on Qt4.8 only makes sense on OpenGL Hardware! If you don�t have
>>> OpenGL
>>> HW there is absolutely no point in choosing Qt4.8-QPA over Qt4.8-QWS"
>>
>> The wiki is wrong.
>>
>> There's a lot of reason for choosing QPA, regardless of OpenGL support or
>> lack thereof. There are also reasons for choosing QWS instead of QPA, even
>> with OpenGL hardware, if those reasons are stronger than the best
>> adaptation to OpenGL (example: the QWS display server).
>
> Seconded, that wiki line is BS.
>
> Using QPA with the linuxfb plugin on 4.8 for single-process applications is
> way more efficient than QWS, both memory- and FPS-wise. QWS enables
> composition and server-side rendering by default, which has a huge impact for
> the performance of the transfer-to-framebuffer phase. QPA with linuxfb doesn't
> have any of that.
>
> You can disable it when configuring Qt, but there's no documented option, you
> have to pass -D flags manually. If you're doing it, then yes you get similar
> display performance between QWS and QPA. But by default QPA wins.
>
> The only thing QWS buys you is built-in (and ugly) window decorations, as well
> as multi-process support. For everything else it's just a legacy framework
> with lots of overhead and a constant source of performance problems imho.

Is this theory or experience?

My experience is completely different with QPA on 4.8 and the linuxfb 
platform. I tried it a couple of months ago and framerate was clearly 
lower than with QWS. At that time people told me, that the linuxfb QPA 
platform is in worse shape than the linuxfb plugin used by QWS. But 
maybe something changed since 4.8.0?

Sven



More information about the Development mailing list