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 bg-entrybox@2x.png. .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/bg-entrybox@2x.png); background-size: 8px 8px } https://b.hatena.ne.jp/images/v4/public/bg-entrybox@2x.png
Created attachment 377670 [details] test case
Created attachment 377671 [details] test case
It seems that GTK port doesn't have this issue. Is this a Windows pixman issue?
Here are the result of performance profiler: screenshot: https://ibb.co/BgTZH5Z text: https://gist.github.com/fujii/a22959088021063744c6ca53a28ff4a6
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?
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.
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.
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.
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.
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.
Created attachment 386820 [details] test content to check scaling filters
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.
Chrome and Firefox are using better than bi-linear filter. IE and Edge are using bi-linear.
GraphicsContext::setPlatformImageInterpolationQuality is not implemented for cairo port.
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.
Created attachment 386828 [details] WIP patch
Created attachment 389234 [details] Patch
Created attachment 389235 [details] Patch
Comment on attachment 389235 [details] Patch Clearing flags on attachment: 389235 Committed r255477: <https://trac.webkit.org/changeset/255477>
All reviewed patches have been landed. Closing bug.
<rdar://problem/59049641>