[Qt-qml] Improve performance of image loading in QML on dual core embedded systems

[yuval tal]

Hi,

I was testing Qt4.8/QML performance on a dual-core embedded system. I created a grid with 200 items and showed 21 items in the grid. I noticed that while I scroll, the performance wasn’t so good. After doing a lot of digging and comparison I got to some conclusion which is a bit odd: during scroll, core 0 is running at 100%. That’s fine. The low priority thread that loads the images was running on core 1. This means that the fact that it has a lower priority is meaningless as core 1 was mostly idle so the scheduler was actually letting it run. Every time it finished decoding an image, it copied it to the main thread, which caused a hick-up. I disabled core 1 and scroll performance was MUCH better and images were decoded only when I was not scrolling.

I think a good idea would be to set the affinity of these two threads to the same CPU. That’s a temporary fix. I think that a better fix would be that the image loader, would not immediatelly return the job upon complete, but wait for a good time (when no animations are running for example) to copy the images to the main thread. Anyone has other ideas?

Give it a try if you are facing the same issue. If you want to disable a core on linux do the following:

echo 0 > /sys/devices/system/cpu/cpu1/online

-Yuval

[Jason H]

It also matters greatly what image format you use. PNG takes a lot of CPU.

What I would do is not disable a core, but only copy to the main thread when the image is done loading and needed.
Also look at QPixmapCache. 

Also, if memory serves, QPixmaps are implicitly shared and don't need to be copied between QThreads, but QImage isn't and must me copied.

---

From: yuval tal <yuv...@boxee.tv>
To: qt-...@qt.nokia.com
Sent: Wednesday, February 1, 2012 10:18 AM
Subject: [Qt-qml] Improve performance of image loading in QML on dual core embedded systems

_______________________________________________
Qt-qml mailing list
Qt-...@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-qml

[yuval tal]

Jason, I think that it's already implemented in a way that it's copies only once it's done. There's a worker thread that does that at a low priority. However, once it's done it notifies the main thread, and that causes a hick up. I saw that in QPixmapCache. I guess once loading is done, there's call all the way from the C++ to the declarative view that the source was updated and from what I've seen it's quite an expensive op.

[Bo Thorsen]

You should test if QPixmapCache is actually used. I had a project about
a year ago on Symbian where the cache wasn't working. We wrote our own
cache and solved the problem.

Bo.

Den 01-02-2012 18:28, yuval tal skrev:
> Jason, I think that it's already implemented in a way that it's copies
> only once it's done. There's a worker thread that does that at a low
> priority. However, once it's done it notifies the main thread, and that
> causes a hick up. I saw that in QPixmapCache. I guess once loading is
> done, there's call all the way from the C++ to the declarative view that
> the source was updated and from what I've seen it's quite an expensive op.
>
> On Wed, Feb 1, 2012 at 6:48 PM, Jason H <scor...@yahoo.com
> <mailto:scor...@yahoo.com>> wrote:
>
> It also matters greatly what image format you use. PNG takes a lot
> of CPU.
> What I would do is not disable a core, but only copy to the main
> thread when the image is done loading and needed.
> Also look at QPixmapCache.
>
> Also, if memory serves, QPixmaps are implicitly shared and don't
> need to be copied between QThreads, but QImage isn't and must me copied.
>
>

> ------------------------------------------------------------------------
> *From:* yuval tal <yuv...@boxee.tv <mailto:yuv...@boxee.tv>>
> *To:* qt-...@qt.nokia.com <mailto:qt-...@qt.nokia.com>
> *Sent:* Wednesday, February 1, 2012 10:18 AM
> *Subject:* [Qt-qml] Improve performance of image loading in QML on

> Qt-...@qt.nokia.com <mailto:Qt-...@qt.nokia.com>
> http://lists.qt.nokia.com/mailman/listinfo/qt-qml

>
>
>
>
>
> _______________________________________________
> Qt-qml mailing list
> Qt-...@qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-qml

Bo Thorsen,
Fionia Software.

--

Expert Qt and C++ developer for hire
Contact me if you need expert Qt help
http://www.fioniasoftware.dk

[Adriano Rezende]

On Wed, Feb 1, 2012 at 1:18 PM, yuval tal <yuv...@boxee.tv> wrote:

Hi,

I was testing Qt4.8/QML performance on a dual-core embedded system. I created a grid with 200 items and showed 21 items in the grid. I noticed that while I scroll, the performance wasn’t so good. After doing a lot of digging and comparison I got to some conclusion which is a bit odd: during scroll, core 0 is running at 100%. That’s fine. The low priority thread that loads the images was running on core 1. This means that the fact that it has a lower priority is meaningless as core 1 was mostly idle so the scheduler was actually letting it run. Every time it finished decoding an image, it copied it to the main thread, which caused a hick-up. I disabled core 1 and scroll performance was MUCH better and images were decoded only when I was not scrolling.

I believe this hick-up could be caused by the convertion from QImage to QPixmap in the main thread. The working thread loads them as QImage but they are stored as QPixmap in the main thread.

If that is the case, you could try to avoid this internal convertion creating your own specialized components (storing and painting as QImage), but I never tried that to check if it would avoid this hick-up issue. It's worth mentioning that using QImage for painting is not as optimized as using QPixmap, but it would probably have no visual impact on high end devices depending on the use case.

Br,
Adriano

[Adriano Rezende]

On Thu, Feb 2, 2012 at 5:08 AM, Bo Thorsen <b...@fioniasoftware.dk> wrote:

You should test if QPixmapCache is actually used. I had a project about
a year ago on Symbian where the cache wasn't working. We wrote our own
cache and solved the problem.

 
The problem is that QtQuick1 uses its own pixmap cache internally, so any change you make on QPixmapCache will have no effect. The biggest issue is that this cache has a fixed size and it's not exposed in the public API. So, any application that needs a bigger cache size will have to create its own pixmap cache externally through image providers.

Br,
Adriano