Flash is working too slow using QGraphicsWebView

  • When switching from QWebView to QGraphicsWebView the flash movies in www.youtube.com are being displayed very slow. When I go to fullscreen it starts to work perfect. Is there somehow a way to boost the performance of the flash movies in QGraphicsWebView?

  • troubleshooting: How's the performance if you use only QWebView?

  • Which operating system? Which graphics system are you using?

  • Hi there,

    I've got the same problem, but some more information tough:


    • Qt 4.7.0 with QtWebKit 2.1 week 37 (MeeGo 1.1 stuff)
    • Linux (MeeGo, as you might have guessed)
    • X11
    • Graphicssystem is raster

    What I want to do is basically display web pages. I also want to zoom and scroll them.
    For zooming I found out that the best option is to change the scale of the QGraphicsWebView during zooming, but to change the zoomFactor of it when the user reached the final zoom level. This causes some "jumping" of the page after the zooming, because when changing the zoomFactor the page is re-layouted, but the rendering is much nicer when the zoomFactor is changed (Flash content can resize itself, fonts look nicer especially when using a QGLWdiget as viewport).

    I enabled the TiledBackingStore and use a QGLWidget as viewport, freeze the backing store at appropriate times, and everything flies on most pages.
    On pages with flash content (especially YouTube), the performance is unbearable. Flash videos only play choppy, scrolling and zooming is really bad. I think the reason is, that Flash paints onto a pixmap which is then transferred to the application, and then written to a QPixmap which happens to be a OpenGL texture (if I did understand that correctly).

    So, I tried to switch to a standard viewport. But this gives me even more performance problems: Zooming is very slow, and also scrolling is not quite smooth. I think the problems are again QPixmaps: Turing zooming, the tiles of the backing store have to be scaled, which incurs, as far as I understood, that the pixmaps are loaded from the server side, then are scaled in the client, and sent to the server again after the scaling.
    That was also the reason why I set the zoomFactor after zooming. In that way, the backing store tiles are created with the right size, and no scaling has to be done when painting them. But there is still a whole lot of data to be sent to the server, because on busy pages the pixmaps change a lot (and are big, as they are zoomed already).
    In general, why is QPixmap scaling so slow with the raster engine under X11?

    So, this leaves me with two options: Use OpenGL and have really bad Flash performance, or use the raster engine, and have really bad zooming and not so good scrolling perfomance. I quickly tried -graphicssystem native, but that doesn't look like an alternative ;-).

    Would it be an option to use QImages instead of QPixmaps as tiles buffers for the backing store in order to increase the raster zooming performance? I don't think that on busy pages a lot of pixmaps are painted more often than once, so using QPixmaps does more harm than good. What to you think? Would it be worth a try?

    For the OpenGL case (which I would prefer), I am not sure what I can do there in the general case. But I only want to zoom my web pages, so I could remove the "force Flash to be windowless" hack and use Flash in windowed mode (as the plugin area always remains a rectangle). But then I would have to move/zoom the Flash content on the page somehow manually. Do you have any hint where and how this could be done? What do you think?

  • I tried a couple of the options:

    I removed the "force Flash to be windowless" hack and let flash paint into its own window. After some fiddling I also was able to move the Flash window together with the web-page, but as soon as I zoomed, Flash crashed. I have no idea why (maybe bacause Flash only works properly in windowed mode with QWebView), but as I am not quite keen on searching the reason for this in code I don't have, I gave up on this.

    I saw however that for Meamo Flash is able to paint into a QImage. Would it be possible to do the same under X11? I have a constrained environment, so I would probably be able to find out the default visual used by flash in order to provide it to Flash. Would that improve performance for the OpenGL case? Additionally, I could as well override gdk_default_visual as discussed in http://trac.webkit.org/wiki/QtWebKitPlugins (as I only want to support my compiler/device compination), but again, would OpenGL performance be improved?

    I also tried to replace the QPixmap-buffers in the TiledBackingStore by QImages, but zooming with the raster engine is still rather slow.
    Additionally, when enabling the TiledBackingStore, Flash-videos get somewhat slower. I guess that's because of the frequent update of the backing store.

  • I'm also experiencing slow flash in a QGraphicsWebView in QGraphicsView on linux. Is there any progress on performance increase in this situation?

    I've been looking into overriding gdk_default_visual as this will also let the flash have transparency, but this seems rather drastic and I have no idea what the influence could be for other item in the qgraphicsview. Has this method been tested yet for increased performance with the opengl backend?

  • Greetings,

    I'm also working with a QGraphicsScene + QGraphicsWebView. I'm on Windows Vista + 4.7.2.

    I have to say embedded flash is still slower than in the QWebView, see here: http://developer.qt.nokia.com/forums/viewthread/3937/

    Any insight on why the flash is slower inside a QGraphicsView ? Any workaround ?

    Is the 4.8 likely to improve the situation ?

    Update: on OS-X performance seems slightly better.


  • I've submitted a patch to webkit which solves the problem of flashes being slow in a QGraphicsWebView when using opengl: https://bugs.webkit.org/show_bug.cgi?id=66650

  • Awesome tiftof !

    Is this going be merged in Qt 4.8 ?

    Also it would be interesting to investigate why QGraphicsWebView is slower than QWebView in rendering flash in some configurations.

    See here : http://developer.qt.nokia.com/forums/viewthread/3937/


  • I have no idea yet :p I don't know if patches for webkit are still in time for Qt 4.8. And more importantly: the patch isn't accepted yet in webkit :)

  • Hey tiftof, any news about your patch ? I'm looking forward to use it myself.

  • Bunjee, I lost track of my patch because I got rid of my performance problems. Because of your reply here, I updated my patch and asked for a review but it got rejected and needs more investigation.

    I solved my issue without the patch by forcing the opengl engine to opengl 2 instead of 1: http://doc.qt.nokia.com/latest/qgl.html#setPreferredPaintEngine This solved my performance issue with QGraphicsWebView (see the link to webkit bug report for more info on what was my original performance problem).

    With my problem being solved by switching to the opengl 2 engine, I have to be honest that I don't have much time anymore to investigate this problem further. Hopefully you can solve your problem in the same way. If it doesn't and profiling your application doesn't show that every paint of the QGraphicsWebView triggers a QImage::fromPixmap() call to draw a plugin (which causes my bad flash performance), then our problems probably have a different cause anyway.

    [EDIT: fixed link, Volker]

  • Hello tiftof !

    Thanks for the reply.

    According to Qt documentation:

    bq. By default, the QPaintEngine::OpenGL2 engine is used

    You had to set this flag anyway ?


  • Yes, because I'm using an Intel i915 platform running Linux and Mesa is reporting 1.4 compatibility and not 2.0 because of some missing implementations => Qt will use OpenGl 1 by default on that platform.

  • I have also the same issue in a webview in qml (windows) .. It's far slower than in wekbit (I render my qml in a qglwidget as viewport). Is there any workaround : I have tryed 4.8RC1 but it's the same issue.

Log in to reply

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