Showing animated progress while loading large QML files
I asked this on the mailing list, but thought I might as well also post it here :)
I’m working on a QML based app. where I dynamically load ‘sub’ applications or plugins at runtime. However when running on maemo, loading of all the QML files of such a sub-app. takes quite a long time (5-10 secs, enough for the end user to be annoyed), so I’m wondering if there is a way to at least show an animated loading screen while this is going on. I’ve tried a couple of things, but haven’t really found a satisfying solution:
- Wrap the QML in a Loader: This allows me to show a static loading screen, but as soon as I ask the loader to load the rest of the QML content, all animation is blocked while it’s loading.
- Load the QML in a background thread: This fails because the QML contains a lot of images which in turn creates QPixmaps, which doesn’t work from another thread than the main ui thread :(
I’ve done a number of things to speed up the actual loading itself, but I don’t think I can get it much faster:
- Prefetch the QML, i.e. have the QML engine load the same QML file so it caches the parsed version of the QML
- Prefetch images, i.e. have the image loaded into QPixmapCache ahead of time
Any help appreciated,-pjoe
So far my best bet is to draw progress indication from a separate thread using opengl. I found this article on multithreaded opengl in Qt: http://doc.trolltech.com/qq/qq06-glimpsing.html#writingmultithreadedglapplications
Thanks, I did try worker script .. it doesn’t help :( The issue is that when loading the main QML content the whole ui thread is blocked, so it’s not possible to do any screen updates. And because QML Image items use QPixmaps, the actual instantiation of the QML hierarchy can only be done in the ui thread.
I should also note that the QML content is loaded from resource files, so it’s not getting the data that’s taking time, it’s building the QML hieararchy (and to some extent creating pixmaps as part of that).
I’ll have a look at QProgressDialog, but it looks like it is also supposed to run in the main ui thread. If that’s the case it again doesn’t help here :(
I have to say I come to the same problem. And WorkerScript doesn’t help. Maybe it’s a bug. you should fill a request at http://bugreports.qt.nokia.com
Here is the source I’m using for loading QML (I’ve removed some error handling and debug output for readablility). The time is spent in beginCreate() and completeCreate(), which creates the QML hierarchy and blocks the ui thread.
- void MyDeclarativeView::setSource(const QUrl& a_Url)
- m_Url = a_Url;
- delete m_Root;
- m_Root = 0;
- delete m_Component;
- m_Component = 0;
- m_Component = new QDeclarativeComponent(engine(), m_Url, this);
- QObject *obj = m_Component->beginCreate(rootContext());
- if (QDeclarativeItem *declarativeItem = qobject_cast<QDeclarativeItem *>(obj))
- m_Root = declarativeItem;
- QSize initial = rootObjectSize();
- scene()->setSceneRect(0, 0, initial.width(), initial.height());
I’ve tried loading the QML in a background thread, however this fails because while creating Image items QML will create QPixmaps, which can only be done in the main ui thread :(
So what I thought was to make the progress indication in another thread, but this requires that this thread is able to actually update the display and the only solution I’ve found for that is using opengl, unless somebody know of a way to refresh the display from another thread without opengl.
mohsen, that is of little use if the GUI thread is already blocked by a Qt function, as explained above.
pjoe, I think your openGL may be the only way to circumvent this limitation at the moment, other than hacking in the Qt code itself to see what the holdup is. The only other thing that pops into mind is to see if the scenegraph QML backend is mature enough for your needs. At the DevDays session [qt.nokia.com], it was still very much a research project, but it was on the roadmap shown by the Qt CTO (much to the suprise of the author of the research project, by the way).
As Andre noted, the whole ui thread is blocked during beginCreate and completeCreate, so queued signals or events won’t arrive until the QML loading is completed.
I’ve read about qml-scenegraph, and I think it is definitely the long term solution, but as I understood it is currently based on a branch before 4.7.0, so probably not quite ready for production use … yet.
Unfortunately I’m also facing the problem that opengl is currently broken on the final target system – I’m just using maemo for testing, the end product is running on a custom embedded linux device (also arm based, with opengl hw).
very hackishm & ugly workaround: spawn another process to display an animated overlay?
Sound like a waste of resources, but if you really need it, it may be the escape you need.
Sorry that scenegraph is not far enough for you yet, that does not really suprise me, but it was worth suggesting. There was an interesting demo in the session showing an 8-thread simultaneous rendering of a single QML scene. That was the first time I ever saw multi-threaded UI rendering using a single process…