Bug 36034 – [Qt] GraphicsLayer: Opacity change from zero to non-zero doesn't always have effect with AC

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Kim Grönholm]

Created attachment 50541 [details]
Opacity transition from 0 to 1 in 5s

When a web page has only an element which opacity is zero and the opacity is changed to non-zero, the element doesn't become visible. If the mouse cursor is moved outside the window area and back in, the element redraws with correct opacity. After the element has been drawn once with non-zero opacity, the subsequent opacity changes affect immediately. The bug doesn't occur without AC.

Attached a test case to demonstrate the issue.

[Kim Grönholm]

Created attachment 50544 [details]
patch for the bug #36034

The issue seems to be a bug in QGraphicsScene/QGraphicsItem. Attached a patch which introduces a workaround for it.

[Kenneth Rohde Christiansen]

Comment on attachment 50544 [details]
patch for the bug #36034

Seems sensible. Have you reported the bug to Qt DF?

[WebKit Commit Bot]

Comment on attachment 50544 [details]
patch for the bug #36034

Clearing flags on attachment: 50544

Committed r55967: <http://trac.webkit.org/changeset/55967>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Simon Hausmann]

Comment on attachment 50544 [details]
patch for the bug #36034


> -        m_layer.data()->setOpacity(qMin<qreal>(qMax<qreal>(fromValue + (toValue-fromValue)*progress, 0), 1));
> +        qreal opacity = qBound(qreal(0), fromValue + (toValue-fromValue)*progress, qreal(1));
> +
> +        // FIXME: this is a hack, due to a probable QGraphicsScene bug.
> +        // Without this the opacity change doesn't always have immediate effect.
> +        if (!m_layer.data()->opacity() && opacity)
> +            m_layer.data()->scene()->update();
> +
> +        m_layer.data()->setOpacity(opacity);

It would be good to get a sign-off from Noam on this one and also add a comment here with a link to the bugreport at http://bugreports.qt.nokia.com/ . Updating the entire scene is obviously a very expensive operation, so it would be good to know when we can remove this workaround in the future.

[Noam Rosenthal]

I did a smoke test to this - signed off!

[Noam Rosenthal]

I intend to collect Qt bugs that we needed to work-around to try to look at them deeply with Qt R&D.

[Simon Hausmann]

(In reply to comment #7)
> I intend to collect Qt bugs that we needed to work-around to try to look at
> them deeply with Qt R&D.

Excellent, thanks!

[Noam Rosenthal]

Apparently http://bugreports.qt.nokia.com/browse/QTBUG-7714 was already reported and being worked on.

[Simon Hausmann]

(In reply to comment #9)
> Apparently http://bugreports.qt.nokia.com/browse/QTBUG-7714 was already
> reported and being worked on.

Excellent, looks like the fix is in Qt 4.6.2, which is released. I think we should place an #ifdef around the update at least, to take the faster code path without the expensive update for Qt versions >= 4.6.2.

[Kim Grönholm]

Created attachment 51282 [details]
ifdef the QTBUG-7714 workaround for qt versions lower than 4.6.2

Added the Qt version check as Simon suggested.

[Simon Hausmann]

Thanks Kim and Kenneth :)