In order to achieve fast startup times, and continued smoothness as they run, applications need to be able to instantiate new QML elements - anything from delegates to new tabs etc. - while still maintaining a constant, high frame rate. It is expected that a significant portion of most applications will be lazily loaded and there must not be ugly pausing or skipping in animations or transitions while this is happening.
There are two main stages to creating a QML object tree - compiling the QML file into an internal bytecode form, and running the compiled code to produce the element tree. Currently, both stages occur synchronously (excluding any asynchronicity introduced by network operations) on the main application thread.
It is reasonable to expect that QML file compilation can be made to run in a (single) separate thread. To maintain the current behaviour, and to ensure that the initial minimal subset of an application is compiled as quickly as possible, the compilation must appear to be synchronous and blocking by default. Only if a special asynchronous flag is set should local compilation be threaded. The C++ API should only need a minor alteration to support this, as compilation that involves a remote resource is already non-blocking today and consequently all the appropriate progress notification signals exist. Even the case involving remote resources should see a performance improvement as even though it behaves in a non-blocking fashion today, as all the work is still being done on the main thread there will be skips and pauses.
It is probably unnecessary to expose much new API to QML to allow applications to effectively utilise this new behaviour. At the very least, the Loader element should gain an asynchronous property that will enable support. Loaded components that involve a network resource should be asynchronous by default.
It is not clear how imperative QML APIs like Qt.createComponent() or Qt.createQmlObject() should be extended. One interesting idea is to not extend the API at all, but instead allow them to be used from within a WorkerScript which would automatically enable non-blocking behaviour. This has the added benefit of encouraging people to use WorkerScript, and encouraging the QML developers to make WorkerScript easier to use.
Add separate-thread support to QDeclarativeDataLoader
- Remove QDeclarativeEngine thread dependencies from QDeclarativeCompiler
QDeclarativeScriptData is initialised in loader thread Engine's meta type hash is modified in loader thread, and read in main thread Review instances of QDeclarativeCleanup Imported libraries are loaded in the loader thread. Add another plugin interface and deprecate the one with initializeEngine().
- Make QDeclarativeEnginePrivate::Locker class skip locking when possible.