Bug 201326 – [Cairo] Use CAIRO_FILTER_BILINEAR for image tile painting with InterpolationQuality::Default

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[Fujii Hironori]

Created attachment 377669 [details]
test case

[cairo] show painting on Hatena Bookmark

1. Start WinCairo MiniBrowser (both WK1 or WK2 can reproduce this issue)
2. Go to https://b.hatena.ne.jp
3. Drag the thumb of scroll bar

All entries have a background image tile of 16x16 PNG [e-mail].

.entrylist-contents {
	border-top: 4px solid #999;
	border-bottom: 1px solid #ececec;
	height: 100%;
	-webkit-box-sizing: border-box;
	box-sizing: border-box;
	background: url(/images/v4/public/[e-mail]);
	background-size: 8px 8px
}

https://b.hatena.ne.jp/images/v4/public/[e-mail]

[Fujii Hironori]

Created attachment 377670 [details]
test case

[Fujii Hironori]

Created attachment 377671 [details]
test case

[Fujii Hironori]

It seems that GTK port doesn't have this issue.
Is this a Windows pixman issue?

[Fujii Hironori]

Here are the result of performance profiler:
screenshot: https://ibb.co/BgTZH5Z
text: https://gist.github.com/fujii/a22959088021063744c6ca53a28ff4a6

[Fujii Hironori]

Here is the profiling result of GTK port on Linux.
https://gist.github.com/fujii/4506adb118b235c9272d574b50343434
It takes SSE2 path. 
Why does pixman take the general path on Windows?

[Fujii Hironori]

GTK port can reproduce this issue by changing zoom factor.

1. Start GTK MiniBrowser
2. Open Attachment 377671 [details]
3. Zoom in
4. Drag the thum of scroll bar

Painting is slow.

[Fujii Hironori]

Created attachment 386401 [details]
Patch to use CAIRO_FILTER_BILINEAR for cairo_pattern

This patch solves this issue.

The profiling result (Comment 4) shows bits_image_fetch_separable_convolution_affine_normal_a8r8g8b8 is dominant in the test case (comment 2).
The function name implies a separable convolution filter is used.
cairo_pattern default filter is CAIRO_FILTER_DEFAULT.
CAIRO_FILTER_DEFAULT is CAIRO_FILTER_GOOD.
Cairo uses PIXMAN_FILTER_SEPARABLE_CONVOLUTION for CAIRO_FILTER_BEST and CAIRO_FILTER_GOOD.
IIUC, Pixman SSE2 has fast paths for BILINEAR and NEAREST filter, but for PIXMAN_FILTER_SEPARABLE_CONVOLUTION.
Then, the generic implementation generic_composite_rect is used.

[Fujii Hironori]

Created attachment 386403 [details]
test case scaling a tile image by 0.75x

There is a comment in _cairo_pattern_analyze_filter:
https://github.com/freedesktop/cairo/blob/f93fc72c0c3e158982740015304389192ce8a567/src/cairo-pattern.c#L3438

>  /* Use BILINEAR for any scale greater than .75 instead
>   * of GOOD. For scales of 1 and larger this is identical,
>   * for the smaller sizes it was judged that the artifacts
>   * were not worse than the artifacts from a box filer.
>   * BILINEAR can also be used if the scale is exactly .5
>   * and the translation in that direction is an integer.
>   */

Cairo uses BILINEAR filter if the filter is CAIRO_FILTER_GOOD and the scale factor is greater than 0.75.

If the scale factor is less than or equal to 0.75, the issue happens.
The attached test case is scaling 16x16 image to 12x12, which is 0.75 scale factor.
The issue happens if it is opened with 1.0 device scale factor display.

[Carlos Garcia Campos]

I'm ok with using bilinear instead of good, it would be nice to check if there's any big difference in the image quality, but I guess there isn't. I wonder if we should also change from good to bilinear in drawSurface(), or maybe use bilinear for InterpolationQuality::Default and good for InterpolationQuality::Medium.

[Fujii Hironori]

Thank you for the comment.

Yeah, drawSurface is also using good. I'm also wondering how should I do.

I guess using bi-linear for down scaling may cause perceivable differences.

  Image resize in browsers is broken - Uploadcare Engineering blog
  https://blog.uploadcare.com/image-resize-in-browsers-is-broken-e38eed08df01

If Safari, Chrome and Firefox are using bi-linear for down scaling, I think it would be a good idea to use bi-linear in WebKit cairo integration part. I will check them (after my holiday break).
If they are using better filter than bi-liner, I'm planning to fix the issue in pixman side.

[Fujii Hironori]

Created attachment 386820 [details]
test content to check scaling filters

[Fujii Hironori]

Created attachment 386821 [details]
[screenshot] Safari

Safari is using bi-liner for tiling painting and the first single img painting, better filter for the second single img painting.

Otter browser for Windows also does so.

[Fujii Hironori]

Chrome and Firefox are using better than bi-linear filter.
IE and Edge are using bi-linear.

[Fujii Hironori]

GraphicsContext::setPlatformImageInterpolationQuality is not implemented for cairo port.

[Fujii Hironori]

ImageQualityController::chooseInterpolationQuality chooses
InterpolationQuality::Low for animated resizing, InterpolationQuality::Default for non-resizing.

I think InterpolationQuality::Low should be the nearest filter, 
InterpolationQuality::Default should be the bi-linear for tile painting, and the best filter for a single image painting.

[Fujii Hironori]

Created attachment 386828 [details]
WIP patch

[Fujii Hironori]

Created attachment 389234 [details]
Patch

[Fujii Hironori]

Created attachment 389235 [details]
Patch

[Fujii Hironori]

Comment on attachment 389235 [details]
Patch

Clearing flags on attachment: 389235

Committed r255477: <https://trac.webkit.org/changeset/255477>

[Fujii Hironori]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/59049641>