In Qt6 Quick, using QQuickAsyncImageProvider is the recommended way to support multi-threaded asynchronous image loading, which involves implementing the requestImageResponse method to return a QQuickImageResponse* to the QML engine. The response should emit the finished signal when it has done the job (successfully or not).
In the example provided by Qt doc, the image response subclass, during the construction, builds a QRunnable task (which is also a QObject), connects the task's custom done signal to its custom handleDone slot (which would emit finished) and finally transfers the task to a QThreadPool for execution.
My question: is it possible that the response finishes its job very quickly and the finished signal is emitted before the requestImageResponse method returns the pointer? How is it guaranteed that the engine can catch and handle all the finished signals?
......On second thought, maybe it's the qt event-loop mechanism that guarantees it:
{ // this may be how the engine uses the provider auto response = provider->requestImageResonse(...); // suppose now the runnable has done the job and emits "done" // but the signal is just queued up to the current event-loop // and the "handleDone" slot would not get executed // until the event-loop finishes handling this piece of code QObject::connect(r, &QQuickImageResponse::finished, ...); // now the response is well-connected to the engine} // finally the event-loop can execute the "handleDone" slot of the response{ ...... // in the image response subclass // void handleDone(QImage image) { this->image = image; emit finished(); // the signal is guaranted to be caught by the engine }} Is my guess correct?