Hmm, Pelle Documentation tells that asynchronous works only with local filesystem, I am not sure if resource file counts as local filesystem - http://doc.qt.nokia.com/4.7-snapshot/qml-image.html#asynchronous-prop
It probably won't help, but if I was desperate I would have tried deploying images to file system and not to resource file and then tried asynchronous property. Best regards, Artem. On Sep 29, 2011, at 9:11 PM, Pelle Johnsen wrote: > We actually did tests with asynchronous=true and found no measurable > difference :( > > In our case we are loading image data from resource files, so it may be that > you can get some benefit if you have a case where getting the image data > itself takes time (e.g. over the network). But because of before mentioned > issues with QPixmap, they will eventually still 'queue up' on the main ui > thread. > > -Pelle > > On Thu, Sep 29, 2011 at 3:02 PM, Artem Marchenko <[email protected]> > wrote: > Just a quick check: > If you are using lots of local images, have you made sure that your Image > elements has asynchronous property set to true? It may have significant > impact on the startup performance. > > If I get it correctly synchronous loading of local images doesn't mean just > frozen UI while image is being loaded, it also means that all of your images > are going to be loaded sequentially, one after another, not in parallel. That > could delay UI a lot if you've got many local images to load. > > Best regards, > Artem. > > On Sep 28, 2011, at 12:28 AM, Todd Rose wrote: > > > 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
