trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: September 2013

Re: Re: [trinity-devel] My opinion on Trinity project quality

From: "Timothy Pearson" <kb9vqf@...>
Date: Thu, 19 Sep 2013 13:35:42 -0500
> On Thursday 19 September 2013 12:35:17 Aleksey Midenkov wrote:
>> >  Qt4 decided that they wanted to be a compositor instead of
>> > passing compositing off to the native display server, and most of the
>> > performance problems and drawing limitations stem from this decision.
>>
>> Hmm, interesting news. Ok, that's a good reason to stay with Qt3. I
>> don't like how Qt4 performs either.
> It's not interesting news, it's just wrong. Qt's internal rendering
> doesn't
> depend on whether compositing is used or not. Even more a compositor would
> not
> even be able to make use of any optimizations done inside Qt for the
> composited case, because there is no way for the compositor to know that
> the
> app "supports" it. Compositing on X11 happens behind the scenes of the
> window.
> The window doesn't and doesn't need to know that it gets composited.
>
> Cheers
> Martin
>
> Maintainer of the X11 Compositor of the KDE Plasma Workspaces

My apologies; I was not referring to compositing in the window management
sense, I was referring to the new painting system code in Qt4 (Arthur:
http://www.trinitydesktop.org/docs/qt4/qt4-arthur.html), and even more
specifically to things like the backing store introduced in Qt 4.1
(http://doc.qt.digia.com/qq/qq16-background.html).

While I don't have a link to it handy, newer versions of Qt essentially
are just blasting pre-rendered pixmaps to the X server on every change
(graphics system raster).  In fact, Qt is working hard on removing native
bindings and replacing them with their software-only renderer
(http://blog.qt.digia.com/blog/2009/12/18/qt-graphics-and-performance-the-raster-engine/)
for performance reasons.

I have to ask: If the XRender system worked so well in Qt3, even over the
network, why is the XRender system working so badly in Qt4 that Nokia now
needs to fall back on a software rasterizer?  What changed?

Even over a fast RDP connection (yes, RDP, not X11 native, though X11
native shows the same effect) I can tell the difference between Qt3 and
Qt4 apps just from their redraw speed alone.  Essentially, *as far as I
can tell*, if your remote desktop is not blasting entire screens over the
network on each update (e.g. some old versions of VNC), you will see a
definite performance difference between Qt3 and Qt4 apps.  My best *guess*
is that the graphics server does not know what changed when a Qt4 app
updates its visible contents, therefore it sends the entire contents of
the window over the remote desktop connection, even if 99% of the pixels
are the same.

I probably got some of the Qt4 stuff above wrong as usual, but I don't
really have the time or desire to keep up with the latest Qt4 information
as I don't use Qt4 very often. :-)  All I know is that there *is* a
performance drop on many systems (unquantified, though this seems most
severe on non-VNC remote desktops) that so far has eluded the teams at
Nokia, the various KDE SC developers, the TDE developers, and various
application developers such as Xilinx.

Tim