third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html - Issue 2039943003: Convert fast/repaint/window-resize*.html into reftests

Side by Side Diff: third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered.html

Issue 2039943003: Convert fast/repaint/window-resize*.html into reftests (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Created 4 years, 6 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« third_party/WebKit/LayoutTests/fast/repaint/resources/window-resize-repaint.js ('K') | « third_party/WebKit/LayoutTests/fast/repaint/resources/window-resize-repaint.js ('k') | third_party/WebKit/LayoutTests/fast/repaint/window-resize-background-image-fixed-centered-composited.html » ('j') | third_party/WebKit/LayoutTests/fast/repaint/window-resize-vertical-writing-mode.html » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 <!DOCTYPE html>	1 <!DOCTYPE html>

2 <script src="resources/window-resize-repaint.js"></script>	2 <script src="resources/window-resize-repaint.js"></script>

	3 <script>

	4 // Scaled background images in test and reference don't fully match.
	pdr. 2016/06/07 22:44:46 Are these bugs? I would have expected these to mat Are these bugs? I would have expected these to match. Xianzhu 2016/06/08 17:00:31 The differences are not visible with my eyes. I gu Show quoted text 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). Xianzhu 2016/06/08 17:46:40 (The above description about C may be inaccurate. Show quoted text 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. Xianzhu 2016/06/08 18:29:07 https://codereview.chromium.org/2052563002/ works Show quoted text 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.
	5 if (window.testRunner)

	6 testRunner.dumpAsText();

	7 </script>

3 <style>	8 <style>

4 body {	9 body {

5 background-image: url(resources/apple.jpg);	10 background-image: url(resources/apple.jpg);

6 background-size: cover;	11 background-size: cover;

7 background-attachment: fixed;	12 background-attachment: fixed;

8 background-position: center;	13 background-position: center;

9 }	14 }

10 </style>	15 </style>

OLD	NEW