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

[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 <scorp1us at yahoo.com
> <mailto:scorp1us at 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 <yuvalt at boxee.tv <mailto:yuvalt at boxee.tv>>
>     *To:* qt-qml at qt.nokia.com <mailto:qt-qml at 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
>
>     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
>
>     _______________________________________________
>     Qt-qml mailing list
>     Qt-qml at qt.nokia.com <mailto:Qt-qml at qt.nokia.com>
>     http://lists.qt.nokia.com/mailman/listinfo/qt-qml
>
>
>
>
>
> _______________________________________________
> Qt-qml mailing list
> Qt-qml at 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