Inconsistent border-radius rendering
Reported by
johannes...@flachware.com,
May 31 2018
|
||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36 Steps to reproduce the problem: 1. Create two div elements with a 1px border 2. Apply a border-radius (e.g. 4px) to all corners of the first div 3. Apply the same border-radius to s o m e of the corners of the second div What is the expected behavior? The rendering of the corners with the applied border-radius should look identical. What went wrong? Applying the border-radius only to some of the corners lets the border-radius look slightly smaller. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 67.0.3396.62 Channel: stable OS Version: OS X 10.13.4 Flash Version:
,
May 31 2018
,
May 31 2018
Could you please attach the html file you used to produce this image? I believe this is due to the different paths for border painting when the edges/corners are not all the same. I suspect we won't fix it, because we can't without making the most common case worse.
,
May 31 2018
Thanks for the test case.
,
May 31 2018
I can't reproduce Mac or Linux. Could you please navigate to "chrome://gpu" and paste the result in here? This might be somehow GPU specific.
,
May 31 2018
You are right – I can only reproduce the issue when hardware acceleration is disabled. --- Graphics Feature Status Canvas: Software only. Hardware acceleration disabled CheckerImaging: Disabled Flash: Software only. Hardware acceleration disabled Flash Stage3D: Software only. Hardware acceleration disabled Flash Stage3D Baseline profile: Software only. Hardware acceleration disabled Compositing: Software only. Hardware acceleration disabled Multiple Raster Threads: Disabled Native GpuMemoryBuffers: Software only. Hardware acceleration disabled Rasterization: Software only. Hardware acceleration disabled Surface Synchronization: Disabled Video Decode: Software only. Hardware acceleration disabled Viz Service Display Compositor: Disabled WebGL: Disabled WebGL2: Disabled Problems Detected GPU process was unable to boot: GPU access is disabled in chrome://settings. Disabled Features: all Viz service display compositor is not enabled by default. Disabled Features: viz_display_compositor Checker-imaging has been disabled via finch trial or the command line. Disabled Features: checker_imaging Version Information Data exported 2018-05-31T16:27:51.891Z Chrome version Chrome/67.0.3396.62 Operating system Mac OS X 10.13.4 Software rendering list URL https://chromium.googlesource.com/chromium/src/+/babbbb5b433370f9a7feeb9f98a57599ad1c4676/gpu/config/software_rendering_list.json Driver bug list URL https://chromium.googlesource.com/chromium/src/+/babbbb5b433370f9a7feeb9f98a57599ad1c4676/gpu/config/gpu_driver_bug_list.json ANGLE commit id 702006f4a07e 2D graphics backend Skia/67 78b60f4ff13b83da98ae2bca85aaef0a98b61098- Command Line /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --flag-switches-begin --enable-experimental-web-platform-features --flag-switches-end Driver Information Initialization time 0 In-process GPU true Passthrough Command Decoder false Direct Composition false Supports overlays false Sandboxed false GPU0 VENDOR = 0x0000, DEVICE= 0x0000 Optimus false AMD switchable false Driver vendor Driver version Driver date Pixel shader version Vertex shader version Max. MSAA samples Machine model name Machine model version GL_VENDOR GL_RENDERER GL_VERSION GL_EXTENSIONS Disabled Extensions Disabled WebGL Extensions Window system binding vendor Window system binding version Window system binding extensions Direct rendering Yes Reset notification strategy 0x0000 GPU process crash count 0 Compositor Information Tile Update Mode Zero-copy Partial Raster Enabled GpuMemoryBuffers Status ATC Software only ATCIA Software only DXT1 Software only DXT5 Software only ETC1 Software only R_8 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT R_16 Software only RG_88 Software only BGR_565 Software only RGBA_4444 Software only RGBX_8888 Software only RGBA_8888 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT BGRX_8888 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE BGRX_1010102 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT RGBX_1010102 Software only BGRA_8888 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT RGBA_F16 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT YVU_420 Software only YUV_420_BIPLANAR GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT UYVY_422 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT Display(s) Information Info Display[69475729] bounds=[0,0 1920x1200], workarea=[0,23 1920x1177], scale=1, external. Color space information {primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL} Bits per color component 8 Bits per pixel 24 Info Display[69733442] bounds=[-1440,0 1440x900], workarea=[-1440,23 1440x877], scale=2, external. Color space information {primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL} Bits per color component 8 Bits per pixel 24 Video Acceleration Information
,
May 31 2018
,
May 31 2018
A software rendering issue, it seems. Over to Skia to see if they can explain. I suspect that borders drawn using a path and those drawn using an RRect look different. Possibly on GPU the code ends up being the same which would explain the issue not reproducing there.
,
May 31 2018
Cary, mind helping take a look at this path/geometry issue?
,
May 31 2018
,
May 31 2018
I can't repro in Skia by comparing drawRoundRect (all corners the same) and drawRRect (each corner may be different). What Skia primitive is called in these cases?
,
May 31 2018
I see that under some circumstances drawDRRect is called. Is it possible that Blink is constructing the inner and outer contours itself?
,
May 31 2018
{
"command" : "DrawRRect",
"coords" :
[
[ 8.5, 8.5, 59.5, 59.5 ],
[ 3.5, 3.5 ],
[ 3.5, 3.5 ],
[ 3.5, 3.5 ],
[ 3.5, 3.5 ]
],
"paint" :
{
"antiAlias" : true,
"color" : [ 255, 0, 0, 255 ],
"filterQuality" : "low",
"strokeWidth" : 1,
"style" : "stroke",
"typeface" :
{
"data" : "data/0"
}
},
"visible" : true
},
{
"command" : "DrawDRRect",
"inner" :
[
[ 77, 9, 127, 59 ],
[ 3, 3 ],
[ 0, 0 ],
[ 3, 3 ],
[ 3, 3 ]
],
"outer" :
[
[ 76, 8, 128, 60 ],
[ 4, 4 ],
[ 0, 0 ],
[ 4, 4 ],
[ 4, 4 ]
],
"paint" :
{
"antiAlias" : true,
"color" : [ 255, 0, 0, 255 ],
"filterQuality" : "low",
"typeface" :
{
"data" : "data/0"
}
},
"visible" : true
}
Yup, looks like Blink is using drawDRRect for the zero-radius variant. Kinda strange that we do that...
,
May 31 2018
Based on that geometry, the DRR should match the RR stroke edges. So I guess the expectation is for equivalent stroked-rrect and filled-drrect to draw the same. Skia repro: https://fiddle.skia.org/c/7694438807193f24c2c8271d07830e83 For the stroked RR, the rounded corners do seem to be weighted slightly inward, for SW only. Maybe related to hairline stroke? If I increase the stroke (> 1) they seem to render about the same: https://fiddle.skia.org/c/cce90b2918c0fb7cab167c005dc0866d
,
May 31 2018
Regarding the question of why Blink is using drawDRRect for zero-radius instead of straight drawRRect, I think I found the issue. I'll put out a CL soon (it should also fix this problem, tangentially).
,
May 31 2018
Curious given this is related to software rendering issue and doesn't repro with hardware acceleration enabled, do we need to consider this as M67 stable blocker(tentatively marking as blocker), please correct me and remove blocker label.
,
May 31 2018
,
May 31 2018
,
May 31 2018
The visual difference is really small (I would have never noticed without a magnifier), and this is not a regression. Not a blocker IMO.
,
Jun 1 2018
Sounds like there are two bugs here. The use of drawDRRect sometimes and drawRRect at others is a Blink issue as described in #16. I have removed the Skia folks from this bug and changed the component to track this issue. The other bug described in #15 is Skia-related; I have isolated that here: skbug.com/8034. In short, it is not a design goal for Skia for a pair of round rects to fill the same pixels as a single stroked round rect.
,
Jun 1 2018
,
Jun 1 2018
,
Jun 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e2eef42958b177eaf8cbbdae667c481d0789421c commit e2eef42958b177eaf8cbbdae667c481d0789421c Author: Florin Malita <fmalita@chromium.org> Date: Fri Jun 01 15:42:31 2018 Revisit GraphicsContext:IsSimpleDRRect() heuristics GraphicsContext::FillDRRect() employs several heuristics in order to determine whether a DRRect can be drawn as a (simpler) stroked RRect. A couple of issues: 1) trivial zero-radius corners are rejected because they don't pass the "unconstrained" test (outer_radius == inner_radius + stroke_width). This means we are unnecessarily using a more expensive drawDRRect for borders which happen to have one or more zero-radius corners. 2) anisotropic/non-circular corners diverge from inner/outer contours when drawn as a stroked RRect (most noticeable with thick strokes, because the [outer-inner] contour is not the same geometry as the stroked centered ellipse). We try to guard against #2 with an arbitrary stroke limit, but that is fragile (e.g. the newly added test). To deal with these problems, update the simple-drrect heuristics to a) always accept zero-radius corners b) reject all anisotropic/non-circular radii TEST=ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-005.htm Bug: 848203 , 848605 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I088e98b0afc474162417036e6278a5751f65e73d Reviewed-on: https://chromium-review.googlesource.com/1081309 Reviewed-by: Stephen Chenney <schenney@chromium.org> Commit-Queue: Florin Malita <fmalita@chromium.org> Cr-Commit-Position: refs/heads/master@{#563646} [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/fast/borders/borderRadiusSolid03-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/fast/box-shadow/box-shadow-clipped-slices-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/fast/clip/nested-rounded-rect-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/fast/css/border-radius-non-negative-expected.png [add] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-005.htm [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/linux/fast/borders/border-radius-mask-canvas-border-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/linux/fast/borders/borderRadiusAllStylesAllCorners-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/linux/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-002-expected.png [add] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/linux/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-005-expected.png [add] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/linux/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-005-expected.txt [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/mac/fast/borders/border-radius-mask-canvas-border-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/mac/fast/borders/borderRadiusAllStylesAllCorners-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/mac/fast/css/nested-rounded-corners-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/mac/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-002-expected.png [add] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/mac/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-005-expected.png [add] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/mac/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-005-expected.txt [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/win/fast/borders/border-radius-mask-canvas-border-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/win/fast/borders/borderRadiusAllStylesAllCorners-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/win/fast/css/nested-rounded-corners-expected.png [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/win/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-002-expected.png [add] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/win/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-005-expected.png [add] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/WebKit/LayoutTests/platform/win/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-005-expected.txt [modify] https://crrev.com/e2eef42958b177eaf8cbbdae667c481d0789421c/third_party/blink/renderer/platform/graphics/graphics_context.cc
,
Jun 1 2018
After e2eef42958b177eaf8cbbdae667c481d0789421c, both cases should use drawRRect() and the rounded corners should look the same.
,
Jun 1 2018
Good job everyone!
,
Jun 4 2018
Tried checking the issue on latest chrome version 69.0.3449.0 using Mac 10.13.1, Windows 10 and Ubuntu 14.04. We have seen similar behaviour in the latest chrome version and on the reported version (i.e., 67.0.3396.62). Attaching the screen shot of the same. @Florin Malita: Could you please let us know if we have missed anything in the process and help us in verifying the fix. Thanks!
,
Jun 4 2018
Looks like you zoomed-in - that will hide the difference. Are you looking at the square upper-right corner? That's is not the problem. The issue, as I understand it, is very subtle: the *rounded* corners used to render with slightly different anti-aliasing for the two divs -- see attached. Now they should look identical.
,
Jun 18 2018
The NextAction date has arrived: 2018-06-18 |
||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||
Comment 1 by gov...@chromium.org
, May 31 2018Labels: Needs-Triage-M67