Showing animated progress while loading large QML files

pjoe

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;
if(m_Root)
{
delete m_Root;
m_Root = 0;
}
if(m_Component)
{
delete m_Component;
m_Component = 0;
}
if(!m_Url.isEmpty())
{
m_Component = new QDeclarativeComponent(engine(), m_Url, this);

    QObject *obj = m_Component->beginCreate(rootContext());

    m_Component->completeCreate();

    if (QDeclarativeItem *declarativeItem = qobject_cast<QDeclarativeItem *>(obj))
    {
        m_Scene->addItem(declarativeItem);
        m_Root = declarativeItem;
    }

    if(m_Root)
    {
        QSize initial = rootObjectSize();
        resize(initial);
        scene()->setSceneRect(0, 0, initial.width(), initial.height());
    }
}

}@

mohsen

have you tried QThread too? to implement you own "please wait" dialog?

pjoe

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

is your process running on a loop like "for" or "while"? then you should use QApplication::processEvents(); inside your loop.

mohsen

for making connection between threads you can use Signal and Slots but i prefer to implement a class inherited by QThread

andre

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":http://qt.nokia.com/developer/learning/online/talks/developerdays2010/tech-talks/scene-graph-a-different-approach-to-graphics-in-qt, 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).

pjoe

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

andre

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

pjoe

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

mohsen

even not possible by second executable file?

LangstoniusRex

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

Or, at least I believe that whats happening. :)

http://svn.linuxmce.org/trac.cgi/browser/branches/LinuxMCE-1004/src/qOrbiter/ if you are curious