Thanks Artem. I've tried QML Performance Analyzer and I've gotten it to work against the Simulator but this is primarily a Symbian app and our Simulator build fakes so much stuff that performance testing in that environment isn't really useful. From my debug tracing I see that 5 seconds is spent in the call to declarativeView.setMainQmlFile() and another 2 seconds in showFullScreen(). I'm not sure what I could do about the latter, but I'm reworking the top-level of the UI to use Loaders for anything that isn't absolutely necessary for the initial view. I'm hoping that will make a noticeable difference.
QML WorkerScript might be useful in some other cases, but for us we have 3 core ListViews whose delegates all contain 2 or 3 Image elements (sometimes more). We have custom image providers that scale/crop/transform/composite these images. We could perhaps get rid of some of that but the UI would suffer a bit. I think the only choice here is to try our best to populate list models as needed and live with a few loading delays as the user navigates around the UI. On Tue, Sep 27, 2011 at 2:59 PM, Artem Marchenko <[email protected]> wrote: > Hi Todd > > Have you tried QML Performance Analyzer from the latest Qt Creator? I failed > to get meaningful device data from it, but maybe you could spend more time > with it and force it to work. Also if desktop performance is comparable even > desktop measurements maybe helpful. > > As for a couple of tricks you could use: > > 1) On Harmattan if it's one of your platforms you could use QML booster - > that could help for something like 0.5-1 sec. > > 2) Splash screen certainly helps hiding low performance, maybe will make it > look some 0.5 sec faster > > 3) QML Loader for loading the not super necessary stuff only when you need > > 4) WorkerScript is the only QML native way for multithreading. The problem is > you can exchange only simple types with WorkerScripts, no image stuff possible > > 5) XmlHttpRequest is another possibility for loading data asynchronously, but > if I've got you correctly, your problem is not with getting data, but with > actual instantiation of images > > If anything above doesn't help, you'll probably need to restructure your UI > significantly. I can hardly believe you need that complex UI at start that it > takes whole 7 sec to instantiate. These are just 0.2-0.4KPixels on screen > after all. > > Best regards, > Artem. > > On Sep 27, 2011, at 9:37 PM, Todd Rose wrote: > >> Thanks for the response Pelle. I wonder if it would help if I routed >> all QML Images through one of our native image providers and marked >> them all as asynchronous. Is the QPixmap cache still used even with >> custom native image providers that return QImage? Just loading the >> QML and related images takes 7 seconds in our app. I will look into >> loading only the smallest subset of QML necessary at startup, and >> doing the rest of the UI on-demand or on timers...unfortunately we >> pretty much need the whole UI available at startup, a splash screen or >> progress dialog would look prettier but it doesn't solve the problem. >> -Todd >> >> On Tue, Sep 27, 2011 at 11:12 AM, Pelle Johnsen <[email protected]> >> wrote: >>> From my experience QML does generally suffer a bit from slow startup time, >>> especially on embedded platforms :S >>> In the project I'm working on the 2 main problems we found are: >>> 1. Actually creating instances of QML Items. In a large app. there can be >>> thousands. This can to some extend be helped by splitting up the app and >>> sort of delay/demand loading individual parts, so you get the main UI up as >>> fast as possibly >>> 2. QML Image uses QPixmap which can only be created in the UI thread, making >>> it impossible to load QML in a background thread (not sure if there is some >>> changes to this in 4.8). If you are doing custom Ui you probably have lots >>> of images, which do take time to load up. >>> Also see this forum >>> thread: http://developer.qt.nokia.com/forums/viewthread/3144 >>> -Pelle >>> >>> On Tue, Sep 27, 2011 at 4:58 PM, Todd Rose <[email protected]> wrote: >>>> >>>> We have a relatively large qt-qml application. The back-end is C++ >>>> and front-end ui is about 70 or so QML files. We're currently seeing >>>> very long initial startup times (ten seconds or more) and we'd like to >>>> know if there's any simple things that we can do to mitigate this. >>>> Some of it is in our application domain and we're working on that >>>> part, but the actual loading and rendering of the QML is also a quite >>>> significant portion of overall initial startup time. Are there any >>>> tricks to make loading and initializing the qt and qtmobility >>>> libraries faster? What about the initial QML file load/parse phase? >>>> We have all of our resource files stored in application subdirectories >>>> - would packaging them in a qt resource file make any difference here? >>>> >>>> Thanks in advance, >>>> Todd >>>> _______________________________________________ >>>> Qt-qml mailing list >>>> [email protected] >>>> http://lists.qt.nokia.com/mailman/listinfo/qt-qml >>> >>> >> _______________________________________________ >> Qt-qml mailing list >> [email protected] >> http://lists.qt.nokia.com/mailman/listinfo/qt-qml > > _______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
