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
_______________________________________________ Qt-qml mailing list Qt-qml@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt-qml
