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

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 :(

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.

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.

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...

@Andre .. I believe that should work, thanks ... but I agree - rather ugly.

The other thing I'm looking at is breaking up my QML content, so it can be loaded in several smaller steps instead (using Qt.createComponent / createObject). This should allow the main screen to show up faster and then I load further views afterwards one by one using a Timer, so I can do some progress update while it's loading.

One way we have tackled this with our LinuxMCE control application was to:
create subclass QObject with its own QDeclarative view as well as signals and logic needed for our splash
Connected signals from the objects running in the different threads
When the app transitions from its splash to the gui, we pass the original QObjects QDeclarativeView as a pointer so we can essentially use the same view..