[Development] Proposal: Qt 4.9 release

Romain Pokrzywka romain.pokrzywka at kdab.com
Wed Aug 15 21:35:00 CEST 2012


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.

> 
> In Qt 5, QPA is more complete and works on the desktop systems.
> 
> > Does Qt5-QPA on non-OpenGL hardware perform not worse than Qt4.8-QWS?
> 
> Of course. Performance has nothing to do with it, since in your case
> everything will be running software rendering anyway.



More information about the Development mailing list