[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 dont 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