QWebFrame load() function slows down main GUI thread
I'm developing a GUI application in Qt 4.8.1 that makes use of headless QWebPages and QWebFrames to load web pages in the background for spidering. However, every time pages are loaded, it slows down the main GUI thread's painting event. This behavior exists in Windows (most noticeably), Mac, and Linux.
I have looked into putting various parts of QtWebkit in a new thread by using moveToThread() to try and solve the GUI slow downs, but I can't put anything that derives from QWidget in a thread other than the main GUI thread. Also, QNetworkAccessManager can't be put into a separate thread. Maybe I don't understand threading very well, but the ideal situation would be to load a web page or several simultaneously and be able to interact with the GUI without stuttering in the painting of the GUI elements.
I tried running the Fancy Browser example and this painting slow down behavior can be observed when loading a page that takes longer than half a second to load. Is this a problem with QtWebkit or am I doing something wrong? Any pointers would be appreciated.
As you wrote, and I can confirm that you will be not able to move GUI objects to non-GUI thread.
To be honest, I never observe such behaviour with QWebPage. But when you said that even a Fancy Browser have similar symptoms than maybe something with your environment is wrong.
Did you enable plugins? Maybe one of is a root cause.
Plugins are disabled and Java is disabled. I'm not sure why this is slowing down the main GUI thread. I came across this forum thread that explains a similar issue with QNetworkAccessManager: http://qt-project.org/forums/viewthread/711
The original poster of this forum thread says that he was experiencing delays in the GUI thread with non-responsiveness from the mouse or keyboard on the GUI for about 1.5 seconds. I tried to implement his solution into my code, but I couldn't figure out how to set the QNetworkAccessManager from one thread on a QWebPage on the GUI thread.
I've even tried overriding the QNetworkAccessManager::createRequest() method in a class subclassed from QNetworkAccessManager to try and offload the request to a new QNetworkAccessManager, but with no luck. It appears as though the culprit of the slow downs is coming from the QNetworkAccessManager::createRequest() protected method as it seems to be a blocking operation.