Convert fast/repaint/window-resize*.html into reftests

Convert fast/repaint/window-resize*.html into reftests

to make rect under-invalidations more visible, and show
painting/rasterization errors if any.

BUG=600008
Committed: https://crrev.com/c612643f5283dc92d261ca2b359e918b8b9343e4
Cr-Commit-Position: refs/heads/master@{#399007}

[Xianzhu, 2016-06-07 17:18:01]

Description was changed from

==========
Convert fast/repaint/window-resize*.html into reftests

BUG=600008
==========

to

==========
Convert fast/repaint/window-resize*.html into reftests

to make rect under-invalidations more visible, and show 
painting/rasterization errors if any.

BUG=600008
==========

[Xianzhu, 2016-06-07 17:18:09]

wangxianzhu@chromium.org changed reviewers:
+ pdr@chromium.org

[Xianzhu, 2016-06-07 17:18:10]

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/repaint/resources/window-resize-repaint.js
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/resources/window-resize-repaint.js:6:
{ width: 800, height: 600 }  // width increase
The above changes have two purposes:
1. Use larger sizes so that rect under-invalidations will be shown in the pixel
result (along with smaller tiles forced in base.py);
2. Finish at 800x600 to match the default window size of the reference.

[pdr., 2016-06-07 22:44:46]

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/repaint/resources/window-resize-repaint.js
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/resources/window-resize-repaint.js:6:
{ width: 800, height: 600 }  // width increase
On 2016/06/07 at 17:18:10, Xianzhu wrote:
> The above changes have two purposes:
> 1. Use larger sizes so that rect under-invalidations will be shown in the
pixel result (along with smaller tiles forced in base.py);
> 2. Finish at 800x600 to match the default window size of the reference.

Just FYI (this change is fine) that we run the W3C-SVG-1.1 SVG tests at a
different default resolution. I've filed crbug.com/618117 to fix this.

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/resources/window-resize-repaint.js:13:
if (sizeIndex > 1) {
Why do we only track repaint rects for sizeIndex 2, 3, and 4? Aren't we missing
tracking rects from the initial to the 1st size?

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html:4:
// Scaled background images in test and reference don't fully match.
Are these bugs? I would have expected these to match.

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/repaint/window-resize-vertical-writing-mode.html
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/window-resize-vertical-writing-mode.html:4:
AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA
Could you use a larger font size instead of so much text? The repaint rect
output is over 1,000 lines for these and I worry that will time out on the slow
asan debug bots.

[Xianzhu, 2016-06-08 17:00:31]

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/repaint/resources/window-resize-repaint.js
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/resources/window-resize-repaint.js:13:
if (sizeIndex > 1) {
On 2016/06/07 22:44:46, pdr. wrote:
> Why do we only track repaint rects for sizeIndex 2, 3, and 4? Aren't we
missing
> tracking rects from the initial to the 1st size?

We increase sizeIndex just after resizeTo(), so when sizeIndex is 2, we are here
to collect the repaint rects for the 1st resize.

Adjusted the sequence of statements to make the logic more obvious.

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html:4:
// Scaled background images in test and reference don't fully match.
On 2016/06/07 22:44:46, pdr. wrote:
> Are these bugs? I would have expected these to match.

The differences are not visible with my eyes. I guess this is related to some
implementation details/optimizations about image decoding and scaling. Painting
in the original scale first then in another scale produces different (but not
visible) pixels from painting in the final scale directly. Forcing rasterization
for each painting (by replacing testRunner.layoutAndPaintAsyncThen with
testRunner.capturePixels) seems to fix the issue.

A) 1. paint in original scale; 2. paint in another scale; 3. rasterize
B) 1. paint in the final scale; 2. rasterize
C) 1. paint in original scale; 2. rasterize; 3. paint in another scale; 4.
rasterize

Pixel(A) != Pixel(B); Pixel(B) == Pixel(C).

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/repaint/window-resize-vertical-writing-mode.html
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/window-resize-vertical-writing-mode.html:4:
AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA
On 2016/06/07 22:44:46, pdr. wrote:
> Could you use a larger font size instead of so much text? The repaint rect
> output is over 1,000 lines for these and I worry that will time out on the
slow
> asan debug bots.

Done.

[Xianzhu, 2016-06-08 17:01:20]

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Tool...
File third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Tool...
third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py:1588:
PhysicalTestSuite('compositing', small_tile_flags),
Do you think this is proper?

[pdr., 2016-06-08 17:32:18]

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Tool...
File third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Tool...
third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py:1588:
PhysicalTestSuite('compositing', small_tile_flags),
On 2016/06/08 at 17:01:20, Xianzhu wrote:
> Do you think this is proper?

These choices make sense to me. My only worry is that it will be incredibly
confusing to have a test work differently in compositing/ compared to other
directories. Is there any way to specify the tile size in the test itself via
the internals api?

[Xianzhu, 2016-06-08 17:46:39]

wangxianzhu@chromium.org changed reviewers:
+ chrishtr@chromium.org, enne@chromium.org

[Xianzhu, 2016-06-08 17:46:40]

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html:4:
// Scaled background images in test and reference don't fully match.
On 2016/06/08 17:00:31, Xianzhu wrote:
> On 2016/06/07 22:44:46, pdr. wrote:
> > Are these bugs? I would have expected these to match.
> 
> The differences are not visible with my eyes. I guess this is related to some
> implementation details/optimizations about image decoding and scaling.
Painting
> in the original scale first then in another scale produces different (but not
> visible) pixels from painting in the final scale directly. Forcing
rasterization
> for each painting (by replacing testRunner.layoutAndPaintAsyncThen with
> testRunner.capturePixels) seems to fix the issue.
> 
> A) 1. paint in original scale; 2. paint in another scale; 3. rasterize
> B) 1. paint in the final scale; 2. rasterize
> C) 1. paint in original scale; 2. rasterize; 3. paint in another scale; 4.
> rasterize
> 
> Pixel(A) != Pixel(B); Pixel(B) == Pixel(C).

(The above description about C may be inaccurate. Please just ignore it for
now.)

I think I found the reason: it's because our image scale quality timer. When an
image is scaled, if it has previous pixels, we first scale it from its original
pixels with faster but low-quality algorithm and schedule a timer to scale it in
high quality.

pdr@, chrishtr@, enne@ is there a way to disable the timer and let it scale
directly in high quality in some layout tests? The default behavior prevents us
from writing reftests for scaled images.

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Tool...
File third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Tool...
third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py:1588:
PhysicalTestSuite('compositing', small_tile_flags),
On 2016/06/08 17:32:18, pdr. wrote:
> On 2016/06/08 at 17:01:20, Xianzhu wrote:
> > Do you think this is proper?
> 
> These choices make sense to me. My only worry is that it will be incredibly
> confusing to have a test work differently in compositing/ compared to other
> directories. Is there any way to specify the tile size in the test itself via
> the internals api?

Currently the tile size configurations are initialized when a WebView is
created. I'm not sure if we can change them on the fly from javascript executed
from the WebView.

[Xianzhu, 2016-06-08 18:29:07]

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html
(right):

https://codereview.chromium.org/2039943003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html:4:
// Scaled background images in test and reference don't fully match.
On 2016/06/08 17:46:40, Xianzhu wrote:
> On 2016/06/08 17:00:31, Xianzhu wrote:
> > On 2016/06/07 22:44:46, pdr. wrote:
> > > Are these bugs? I would have expected these to match.
> > 
> > The differences are not visible with my eyes. I guess this is related to
some
> > implementation details/optimizations about image decoding and scaling.
> Painting
> > in the original scale first then in another scale produces different (but
not
> > visible) pixels from painting in the final scale directly. Forcing
> rasterization
> > for each painting (by replacing testRunner.layoutAndPaintAsyncThen with
> > testRunner.capturePixels) seems to fix the issue.
> > 
> > A) 1. paint in original scale; 2. paint in another scale; 3. rasterize
> > B) 1. paint in the final scale; 2. rasterize
> > C) 1. paint in original scale; 2. rasterize; 3. paint in another scale; 4.
> > rasterize
> > 
> > Pixel(A) != Pixel(B); Pixel(B) == Pixel(C).
> 
> (The above description about C may be inaccurate. Please just ignore it for
> now.)
> 
> I think I found the reason: it's because our image scale quality timer. When
an
> image is scaled, if it has previous pixels, we first scale it from its
original
> pixels with faster but low-quality algorithm and schedule a timer to scale it
in
> high quality.
> 
> pdr@, chrishtr@, enne@ is there a way to disable the timer and let it scale
> directly in high quality in some layout tests? The default behavior prevents
us
> from writing reftests for scaled images.

https://codereview.chromium.org/2052563002/ works for scaled images.

[Xianzhu, 2016-06-08 19:11:29]

Rebased on https://codereview.chromium.org/2052563002/ and now all
window-resize*.html are converted to reftests.

[Xianzhu, 2016-06-09 16:55:54]

Smaller tiles caused image differences, perhaps because some differences about
rasterization. Also smaller tiles actually doesn't help reproducing repaint bugs
about rect-under-invalidation because we can't force a rasterization before
repaintTest.

The latest patch removed the change about smaller tiles. May investigate this
separately.

Ptal.

[pdr., 2016-06-09 17:01:05]

On 2016/06/09 at 16:55:54, wangxianzhu wrote:
> Smaller tiles caused image differences, perhaps because some differences about
rasterization. Also smaller tiles actually doesn't help reproducing repaint bugs
about rect-under-invalidation because we can't force a rasterization before
repaintTest.
> 
> The latest patch removed the change about smaller tiles. May investigate this
separately.
> 
> Ptal.

LGTM

[Xianzhu, 2016-06-09 17:04:54]

The CQ bit was checked by wangxianzhu@chromium.org

[commit-bot: I haz the power, 2016-06-09 17:05:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2039943003/100001

[commit-bot: I haz the power, 2016-06-09 17:59:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-09 17:59:02]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Xianzhu, 2016-06-09 20:41:03]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2016-06-09 20:41:04]

The patchset sent to the CQ was uploaded after l-g-t-m from pdr@chromium.org
Link to the patchset: https://codereview.chromium.org/2039943003/#ps120001
(title: " ")

[commit-bot: I haz the power, 2016-06-09 20:41:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2039943003/120001

[commit-bot: I haz the power, 2016-06-09 20:50:30]

Description was changed from

==========
Convert fast/repaint/window-resize*.html into reftests

to make rect under-invalidations more visible, and show 
painting/rasterization errors if any.

BUG=600008
==========

to

==========
Convert fast/repaint/window-resize*.html into reftests

to make rect under-invalidations more visible, and show 
painting/rasterization errors if any.

BUG=600008
==========

[commit-bot: I haz the power, 2016-06-09 20:50:32]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-06-09 20:53:17]

Description was changed from

==========
Convert fast/repaint/window-resize*.html into reftests

to make rect under-invalidations more visible, and show 
painting/rasterization errors if any.

BUG=600008
==========

to

==========
Convert fast/repaint/window-resize*.html into reftests

to make rect under-invalidations more visible, and show
painting/rasterization errors if any.

BUG=600008

Committed: https://crrev.com/c612643f5283dc92d261ca2b359e918b8b9343e4
Cr-Commit-Position: refs/heads/master@{#399007}
==========

[commit-bot: I haz the power, 2016-06-09 20:53:19]

Patchset 7 (id:??) landed as
https://crrev.com/c612643f5283dc92d261ca2b359e918b8b9343e4
Cr-Commit-Position: refs/heads/master@{#399007}

[perkj_chrome, 2016-06-10 11:11:04]

A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/2058053002/ by perkj@chromium.org.

The reason for reverting is: This cl seem to cause layout test failures on Win
and Mac blink bots. 

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win7%20%28dbg%....