Bug 23090 – Redraw issue with width and opacity change

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Simon Fraser (smfr)]

The attached testcase shows that a block with width and opacity changing at the same time shows a redraw issue which leaves an area where the element used to be un-repainted.

[Simon Fraser (smfr)]

Created attachment 26392 [details]
Testcase

[Simon Fraser (smfr)]

Seems to be an issue only when the element toggles between having a layer (opacity < 1) and no layer (opacity == 1).

[Simon Fraser (smfr)]

Created attachment 26393 [details]
Patch, testcase, changelog

[Darin Adler]

Comment on attachment 26393 [details]
Patch, testcase, changelog

> +            } else if (m_style->hasTransform() != newStyle->hasTransform() ||
> +                       m_style->hasOpacity() != newStyle->hasOpacity()) {
> +                // If we don't have a layer yet, but we are going to get one because of a transform or opacity change, then
>                  // we need to repaint the old position of the object

The comment is right, but the code is wrong. This will decide to repaint something that already has a layer if its opacity is going to change. Can we do a better check that gets this right? We want to repaint if "gets own layer" is going to change, so that's what we should be checking.

[Simon Fraser (smfr)]

(In reply to comment #4)
> (From update of attachment 26393 [details] [review])
> > +            } else if (m_style->hasTransform() != newStyle->hasTransform() ||
> > +                       m_style->hasOpacity() != newStyle->hasOpacity()) {
> > +                // If we don't have a layer yet, but we are going to get one because of a transform or opacity change, then
> >                  // we need to repaint the old position of the object
> 
> The comment is right, but the code is wrong. This will decide to repaint
> something that already has a layer if its opacity is going to change. Can we do
> a better check that gets this right? We want to repaint if "gets own layer" is
> going to change, so that's what we should be checking.

This is in a !hasLayer() clause, so it will actually do the right thing.
However, I will tidy up the logic.

[Simon Fraser (smfr)]

Created attachment 26400 [details]
Improved patch

[Darin Adler]

Comment on attachment 26400 [details]
Improved patch

> +    bool hasOpacity() const { return rareNonInheritedData->opacity < 1; }

I'm not a huge fan of this name for the function. What this function means is that you have non-standard opacity, non-opaque opacity. It says nothing about whether you have any CSS opacity rules, for example. You could have one saying opacity: 1.

But the real problem is it doesn't make sense to say that a fully opaque object with an opacity of "1" does not have opacity.

I'd suggest just saying opacity() < 1 at the call site, or coming up with a better name for this helper function.

r=me with or without a change to that

[Simon Fraser (smfr)]

I changed it to test opacity() < 1 at the call site.

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	LayoutTests/ChangeLog
	A	LayoutTests/fast/repaint/create-layer-repaint.html
	A	LayoutTests/platform/mac/fast/repaint/create-layer-repaint-expected.checksum
	A	LayoutTests/platform/mac/fast/repaint/create-layer-repaint-expected.png
	A	LayoutTests/platform/mac/fast/repaint/create-layer-repaint-expected.txt
	M	WebCore/ChangeLog
	M	WebCore/rendering/RenderObject.cpp
Committed r39588