Important: Please read the Qt Code of Conduct -

QWebPage/QWebFrame Slowing Down GUI

  • Hi

    I'm trying to do some preloading of web pages behind the scenes, and then cache everything to display later.

    I tried directly creating a QWebPage without displaying it, but that caused some pretty bad GUI slowdowns. I did some investigations, and I heard problems where people were having blocking issues with the QNetworkAccessManager inside the QWebFrame. To take care of this, I put the network stuff inside a thread.

    However, the blocking continues. I've narrowed it down to this line, where pReply is the QNetworkReply from the networking thread:

    I do not believe setHtml is blocking, but it definitely seems to be messing with the GUI's responsiveness for a solid 1-1.5 seconds. I would move the page into another thread, but we all know that wouldn't work.

    Any ideas? I'm thoroughly stumped

  • Any suggestions? Still stuck on this and haven't made any new progress :(

  • I've narrowed down the issue to the actual painting of the frame.

    What I think is happening is that any form of setContent() is blocking the event loop from processing anything quickly enough, until setContent is finished and the frame has been painted.

    Can I somehow increase the priority of one widget over another?

  • How do you use your threads? Take a look here:

    Can you show your code where the thread is created and how do you get reply back into main thread. I have done this time ago and haven't saw any kind of slow down.

    Have you looked at QNetworkDiskCache?

  • Hi Acerextensa,

    I have all my network stuff inside the run() function of a QThread, and then when it finishes, emits a signal to let me know. I made sure to call exec() at the end of run(), and call exit() when I finish.

    Unfortunately, I don't think the network activity is the bottleneck here.

    Here's my QThread class anyway:

    @void NetworkWorker::run() {
    this->NAM = new QNetworkAccessManager();
    QObject::connect(NAM, SIGNAL(finished(QNetworkReply*)), this, SLOT(requestComplete(QNetworkReply*)));

    QNetworkRequest *request = new QNetworkRequest(this->url);
    request->setRawHeader("charset", "utf-8");
    request->setRawHeader("Connection", "keep-alive");


    void NetworkWorker::requestComplete(QNetworkReply *pReply) {
    emit finishedLoading(pReply);

  • Follow the link I have posted for you. And why do you create QNetworkRequest dynamically and didn't delete it at all... Like I've said no slow down detected by testing... Post your entire project if you can... maybe the problem is somewhere else...

  • That link was a good read, thanks. I'll try subclassing as a QObject instead of QThread from now on. And good catch, I completely overlooked that.

    On another note, I profiled the application to solidify what exactly is causing the issue. Here's a picture showing what's happening. The red circle is the part that's causing the issue, and the green circle is my NetworkWorker in its own thread. !!

    In the the trouble area, QWebSettings::handle is eating up most of the resources. From what I see, it keeps calling QRectF::width a bunch of times. Part of rendering the webpage maybe?

  • Did you make any progress on this or find a solution?

  • Unfortunately, I haven't. Any QWebView seems to really mess with the gui thread.

Log in to reply