Qt 4.7 WebPage is a widget??



  • Hi!

    I have been a long time developing an app using Qt 4.5. Everything worked fine but Webkit had a memory leak and everytime that I loaded a web page I lost memory so I updated to 4.7 which has supposedly fixed the bug. More info about this bug here:

    https://bugs.webkit.org/show_bug.cgi?id=24458

    The problem that arises now is that I create QWebPages inside threads and this should not be a problem since QWebPage is the non widget QWebView. It extends from QObject but the compiler says:

    "ASSERT failure in QWidget: "Widgets must be created in the GUI thread."

    in Qt 4.5 they can be created...

    Is this a bug?



  • [quote author="DavidGOrtega" date="1294216027"]
    The problem that arises now is that I create QWebPages inside threads and this should not be a problem since QWebPage is the non widget QWebView.
    [/quote]

    Doing that is incorrect.

    QWebPage is not thread safe, the documentation does not mentioned it is. It relies on non-thread safe component like QStyle.



  • Hi Benjamin, many thanks for the answer.

    Be or not thread safe is not a big deal actually, the key thing is why the compiler is telling that. It's supposed that QWebPage is widget free, if not Qt documentation should not say that.

    The worst thing is that if I don't create the QWebPage inside the run method and I use it as a member of the QThread derived class arises a segmentation fault since Wdigets can't be accesed throught QThreads... but? How the hell is QWebPage suppossed to be a QObject instead of a QWidget?

    I suppose that there is some kind of arquitecture failure and QWebPage relies in a Widget component that is breaking the hole thing...



  • [quote author="DavidGOrtega" date="1294232764"]
    Be or not thread safe is not a big deal actually, the key thing is why the compiler is telling that. It's supposed that QWebPage is widget free, if not Qt documentation should not say that.
    [/quote]

    Widget free in the sense that you do not need anything on screen to render the content. And you can implement your own QWidget on top instead of QWebView. We still need widget to render the form elements in the page.

    I do not consider this as a bug. Running WebKit in a secondary thread is a really bad idea.



  • bq. I do not consider this as a bug. Running WebKit in a secondary thread is a really bad idea.

    They are different isolated instances and they are not race problems involved...
    In fact, I believe that QWebView runs different QWebPages instances in different threads.
    Why exactly is a bad idea to run a QWebPage in a thread?



  • QWebPage is a GUI element (it uses pixmaps, QStyle and so on). In Qt you're not allowed to use any GUI elements from other threads but the main thread. That's it.



  • Indeed. It sounds like in theory, running webkit in a secondairy thread could be a great idea. You can render a page into an image as a preview, for instance. Would be perfect to do in a background thread.



  • In theory, making the GUI classes reentrant would be great. In practice, I don't expect it to come very soon... :)



  • In practice I use QWebPage in a server in Qt 4.5 to bring server side javascript with native code accesible throught wrappers, like node.js and others does.

    Coming to Qt 4.7 everything breaks...



  • [quote author="DavidGOrtega" date="1294248371"]In practice I use QWebPage in a server in Qt 4.5 to bring server side javascript with native code accesible throught wrappers, like node.js and others does.

    Coming to Qt 4.7 everything breaks...[/quote]

    Why not use QScript directly if it is just about using Javascript on server side?



  • [content removed - copy post - Alexandra]



  • viv.ojha are you repeating the same as Benjamin!!????

    Benjamin, I have found much more faster using the engine directly than using QScriptEngine not only that but I using other modules, that are much more compatible with QWebPage than with QScriptEngine since QWebPage is DOM based and the scriptengine not, like the debug based enviroment that I have done.

    I'm thinking in issolate the QWebPage in a executble accesed with the QProcess but I haven't found good points on it. That direction should solve aldso the Webkit memory leaks.

    Can you point an example to me?

    Anyway I can't undestand when documentation says "...widget-less enviroment..."

    Thanks



  • [quote author="DavidGOrtega" date="1294390387"]
    Benjamin, I have found much more faster using the engine directly than using QScriptEngine not only that but I using other modules, that are much more compatible with QWebPage than with QScriptEngine since QWebPage is DOM based and the scriptengine not, like the debug based enviroment that I have done.
    [/quote]

    QtScript used to be a separate engine but it is now written on top of JavascriptCore from WebKit so it has about the same speed.
    As you said, no DOM there though.

    [quote author="DavidGOrtega" date="1294390387"]
    I'm thinking in issolate the QWebPage in a executble accesed with the QProcess but I haven't found good points on it. That direction should solve aldso the Webkit memory leaks.

    Can you point an example to me?
    [/quote]

    This sounds like a good plan IF you do not use shared resources like HTML 5 databases, cookies, etc.

    I think youl should still evaluate QtScript.

    [quote author="DavidGOrtega" date="1294390387"]
    Anyway I can't undestand when documentation says "...widget-less enviroment..."
    [/quote]

    peppe's description above is accurate. Widget-less does not mean not mean abstracted free from GUI dependencies.

    Maybe you'll understand with examples?:
    -to show the scrollbar in WebKit, we ask the application style to render them, so we rely on QStyle. QStyle is a gui element, it can be provided by the user, it is not thread safe.
    -to render an image, we start by decoding them onto pixmap. Depending on the graphics engine, the pixmap can be a platform pixmap (XPixmap for example). Those are totally unsafe in threads.

    You can use QWebPage without a widget, for example you can render the content on a QImage and print it. BUT, this does not prevent you from relying on all the basic GUI infastructure needed to render the page.



  • Hi Benjamin,

    I evaluated QScriptEngine from the very beginning, as I stated there is no dom in QScripEngine and thats pretty bad for me actually, but the main difference for me is the speed.

    I know that both engines comes from the JavascriptCore, in fact I don't know why they even don't use the same objects... one returns QVariant an the other is QScriptValue, I prefer to have the core and the browser be talking the same... but as I stated also QScriptEngine is much slower, probably because the debugger that has inside...
    If you evaluate a wrong javascript in both QScriptEngine is returning you a failure message and QWebFrame no...

    Just try

    @for (var i=0; i<50000000; i++)
    {
    1+1;
    }@

    and you will note the difference in speed between both...



  • On which version of Qt?



  • bq. On which version of Qt?

    4.5.3



  • [quote author="DavidGOrtega" date="1294501236"]bq. On which version of Qt?

    4.5.3[/quote]

    This was not based on Javascript core. See "http://labs.qt.nokia.com/2009/11/23/qtscript-in-46/":http://labs.qt.nokia.com/2009/11/23/qtscript-in-46/



  • I see... thats why I noted it so slow... but the returned types are still different...
    why aren't they returned as QVariant?



  • [quote author="DavidGOrtega" date="1294502496"]I see... thats why I noted it so slow... but the returned types are still different...
    why aren't they returned as QVariant?[/quote]

    Well, actually, returning QVariant was a big design mistake of QtWebKit. If the javascript team manage to integrate QtScript to QtWebKit, we will deprecate the return as QVariant.

    Simple example you can't do with QVariant:
    -return a Javascript object and interact with it (call functions, set properties, etc)
    -return a JS function() and then call it from C++, or even pass it back to the engine


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.