[Qt-interest] QGraphicsOpacityEffect performance worse than QGraphicsItem::setOpacity()

[marc at mferland.net]

Quoting Jason H <scorp1us at yahoo.com>:

> I haven't used these, but I have the same excitement as you do. I   
> was worried about using them myself for just this reason.
>
> The problem is (as I see it) these are raster effects, which have to  
>  generate and cache their output. I would expect them to not cache  
> if  the StaticContent flag is not set on he source item. However, if  
> it  is set, the it should use a Pixmap or other cache. However this  
> can  only apply in part on some effects. Things like transparency  
> need to  update what is behind them. So there should also be an  
> update region  taken into account.
>
> I haven't had the time to look into look into it if these techniques  
>  are indeed done.
>
> Also, what drivers are you using? Does using a QGLWidget for the   
> view make it better or worse?
>
>
>
>
> ----- Original Message ----
> From: Josiah Bryan <jbryan at productiveconcepts.com>
> To: Qt Interest <qt-interest at trolltech.com>
> Sent: Wed, October 14, 2009 12:54:10 PM
> Subject: [Qt-interest] QGraphicsOpacityEffect performance worse than  
>  QGraphicsItem::setOpacity()
>
> I'm incredibly excited about the new QGraphicsEffect "module" in Qt 4.6.
> Since the release of the beta last night (today?), I've integrated two
> of the effects (opacity and drop shadow) into the project I've been
> working on for the past two months (http://code.google.com/p/dviz/).
>
> What I found, especially with regards to the opacity effect, was quite
> surprising to me. Specifically, the performance of using
> QGraphicsOpacityEffect to cross fade between QGraphicsItem's is
> *considerably* worse than just using QGraphicsItem::setOpacity()
> directly. A 30 frame, 250ms-long cross fade takes > 5 - 10 seconds due
> to painting using QGraphicsOpacityEffect. Whereas using straight
> QGraphicsItem::setOpacity(), we hit around 275ms - 500ms from start to
> completion of the crossfade. (The 250ms is the target time, the time
> between steps in the crossfade is calculated as 250 / 30 (QTimer is used
> to trigger the frames). The actual painting of the items  often causes
> the actual time to take a bit longer than 1ms to complete each frame,
> pushing it out past the 250ms length. When using QGraphicsOpacityEffect,
> we're hitting north of 150ms - 250ms *per repaint*. Under straight
> setOpacity(), its around 1 - 4ms per repaint. And this is a *simple*
> scene - two rectangular QGraphicsItems - and thats it!
>
> An additional blow to my excitement was the performance of
> QGraphicsDropShadowEffect on a simple rectangular custom QGraphicsItem.
> Changing the blur radius, for example, from 1px to 5px takes around
> 1/2second to re-render the scene. (Whereas, when rendering a "cheap"
> drop shadow as just using drawRect() with a different color and offset
> is imperceptibly fast.)
>
> Those are the two major "problems" I've seen in this Qt 4.6 beta - and
> that is on both Windows XP Pro and Linux (FC 8), with both very high end
> graphics cards, dual / quad processor, 4 GB RAM. So the system isn't the
> lag - it seems the library code is (at least on this end.) Anyone else
> seeing similar problems?
>
> Thanks for your time!
>
> Cheers!
> -josiah
>
> --

Have you tried running your application with:
-graphicssystem raster
or
-graphicssystem opengl

Saw this on:  
http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/

Marc