Issue metadata
Sign in to add a comment
|
Unwanted lines in table rendering
Reported by
gianni.t...@gmail.com,
Dec 12 2016
|
||||||||||||||||||||||
Issue descriptionHi to all, my problem occurs only with the Chrome browser (also Crome mobile). This is a simple test page: http://www.domiciliazionelegale.it/prova.html I tried in every way to eliminate the horizontal upper blue line, without success. Also four cells to the table corners should have 25x25 size, and the width of table should be 200px ... In Chrome (Using Chrome inspect) it is not so. It is correct however in FF, IE, Safari. The problem also occurs in Chrome Mobile. I also tried to use reset.css and normalize.css but nothing changes :-( Who can help me? Thank you very much Giovanni
,
Dec 12 2016
Could you please confirm the OS platform and chrome version detail for routing this to appropriate milestone team.
,
Dec 12 2016
This does not reproduce on tip of trunk on Linux, nor M56 on Windows.
,
Dec 13 2016
Attached is the screen of the behavior that I see on MAC OS for chrome version 55.02883.87 Stable. Same is observed on Canary version 57.0.2949.0. Please confirm if this is expected or an issue. Adding 'Needs-Milestone' label, TE will work on the issue as per the feedback provided by user and will add respective milestone.
,
Dec 13 2016
Also confirmed on Android, even worse. I think the Android cross-hatch of background bleeding isa duplicate of https://bugs.chromium.org/p/chromium/issues/detail?id=614130, so assigning to the same group of people. But the line under or over the text is something else, maybe, so not duping the bugs. To bisect, view the page with DevTool device emulation mode, looking for a cross-hatch of lines through the "button", which is actually a table.
,
Dec 13 2016
,
Dec 13 2016
,
Dec 14 2016
Waiting on bisect.
,
Dec 15 2016
Able to reproduce this issue on Mac Retina with Chrome stable version-53.0.2785.143 and Canary. System Details: MAC Retina PRO with Intel HD Graphics 4000 Manual Bisect: --------------------- Good-56.0.2900.0---Revision-427219 Bad-56.0.2901.0----Revision-427541 Bisect Tool Info: --------------- You are probably looking for a change made after 427481 (known good), but no later than 427482 (first known bad). CHANGELOG URL: --------------- The script might not always return single CL as suspectas some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/26ce312cc8b3f53dc76df85e45c17bba93685fc3..43de8ce7588866b2ce0eefa9ccf9f570c22f1df7 Possible suspect: ----------------- https://chromium.googlesource.com/chromium/src/+/43de8ce7588866b2ce0eefa9ccf9f570c22f1df7 Review-Url: https://codereview.chromium.org/2447163002 ericrk@ Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change. Thanks.!
,
Dec 15 2016
Typo in Chrome Version. Issue reproduced in Mac -Chrome Canary Version #57.0.2951.0 , Dev version-57.0.2950.4 & Beta-56.0.2924.28 Thank you..
,
Dec 15 2016
With that bisect it's a Skia GPU backend bug.
,
Dec 15 2016
,
Dec 15 2016
,
Dec 15 2016
In case it helps debug, attached is the SKP for the webpage contents. Sadly, this seems to be a retina-only bug, so I wasn't able to see this issue in the SKP via skia debugger or dm. Is there a way to force these tools to render at HiDPI (2x scale) mode?
,
Dec 16 2016
+mtklein and jcgregorio for dm/debugger tool expertise
,
Dec 16 2016
At least in the .skp file, the background RRect is being drawn via 9 calls (the texture ID is in parentheses): DrawImageRect (6) | DrawRect1 (2) | DrawImageRect (8) ------------------------------------------------------- DrawImageRect (10) | DrawRect2 | DrawImageRect (12) ------------------------------------------------------- DrawImageRect (14) | DrawRect3 (4) | DrawImageRect (16) All the DrawImageRect calls are issued with kStrict_SrcRectConstraint. DrawRect2 is a solid white rect. DrawRect1 and 3 are being called with an ImageShader which has kRepeat_TileMode as its x&y tile mode. This would explain the image in Comment #4 where DrawRect3 is wrapping around and drawing dark on the top. For the images in the OP, I believe several (maybe all) of the DrawImageRects are being converted into kRepeat_TileMode DrawRect calls. This would explain the top 3 draws becoming dark on the bottom and the bottom 3 draws becoming lighter on the top. I will look into where the DrawRect vs. DrawImageRect decision is being made. At the very least the DrawRect calls should be kClamp_TileMode.
,
Dec 16 2016
Image::drawTiledBackground() tries to determine whether one tile covers the whole dest rect, and if so it ends up calling drawImageRect; otherwise it sets up a shader and calls drawRect for repeat behavior. I recall BackgroundImageGeometry had some rounding issues and sometimes snapped tiles/phases incorrectly -- so it's possible we're using a shader+drawRect unnecessarily. I'll take a closer look. @ericrk IIRC SKPs don't capture the image decode controller interaction (decoding/scaling is deferred to Skia, and not performed preemptively). When it comes to image scaling issues, they don't always provide accurate repros.
,
Dec 16 2016
In this case, the SKP in c#14 does work as a repro: 1) SampleApp --picture unwanted_line.skp 2) hit up-arrow to scale 3) observe artifacts I'm guessing applying a scale before playback is enough to repro.
,
Dec 16 2016
Actually the zoom-based repro is misleading: the artifacts are due to anti-aliasing of misaligned edges. I was able to capture something more interesting with --force-device-scale-factor=2 --force-gpu-rasterization --enable-use-zoom-for-dsf (attached). This seems to repro exactly the case in c#4, without any zoom level tweaks: 1) SampleApp --picture layer_0.skp 2) hit 'd' to enable GPU rasterization
,
Dec 16 2016
Hi, I fixed my issue: I created four border and four corner for the table with bigger size. Thanks to all Giovanni
,
Dec 16 2016
The following revision refers to this bug: https://skia.googlesource.com/skia.git/+/8ced688a3a3489ac696e5ee2d10557b389fd4ebf commit 8ced688a3a3489ac696e5ee2d10557b389fd4ebf Author: Robert Phillips <robertphillips@google.com> Date: Fri Dec 16 16:47:46 2016 Add GM for filtering bug For SkFilterQuality we get: High - repros for GPU Medium - repros for both! Low - repros for both! None - doesn't repro For AA quality (with filter quality fixed at High) we get: AA - repros for GPU BW - repros for GPU BUG= 673261 Change-Id: Ibf0644352bfa9d9c0e2d166e396ce9e9799b6d9d Reviewed-on: https://skia-review.googlesource.com/6187 Commit-Queue: Robert Phillips <robertphillips@google.com> Reviewed-by: Florin Malita <fmalita@chromium.org> [add] https://crrev.com/8ced688a3a3489ac696e5ee2d10557b389fd4ebf/gm/filterbug.cpp [modify] https://crrev.com/8ced688a3a3489ac696e5ee2d10557b389fd4ebf/gn/gm.gni
,
Dec 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/09e3482e5b9a4db938957c86056756f12d7103fc commit 09e3482e5b9a4db938957c86056756f12d7103fc Author: skia-deps-roller <skia-deps-roller@chromium.org> Date: Fri Dec 16 20:04:21 2016 Roll src/third_party/skia/ 99ad16488..138ea97c1 (5 commits). https://skia.googlesource.com/skia.git/+log/99ad164886ba..138ea97c1aca $ git log 99ad16488..138ea97c1 --date=short --no-merges --format='%ad %ae %s' 2016-12-16 brianosman Add color space to picture image as a creation parameter 2016-12-16 robertphillips Add GM for filtering bug 2016-12-16 reed hide deprecated SkImage::preroll 2016-12-16 bsalomon move src/gpu/batches -> src/gpu/ops 2016-12-16 bsalomon Rename GrTestBatch and subclasses to Op BUG= 673261 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, see: http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel TBR=msarett@google.com Review-Url: https://codereview.chromium.org/2581253002 Cr-Commit-Position: refs/heads/master@{#439172} [modify] https://crrev.com/09e3482e5b9a4db938957c86056756f12d7103fc/DEPS
,
Dec 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a7e84a029b10a5a8c0b0faf4bda87e54187840fb commit a7e84a029b10a5a8c0b0faf4bda87e54187840fb Author: fmalita <fmalita@chromium.org> Date: Mon Dec 19 19:59:11 2016 Clamp background tiles when possible We're currently always drawing tiled backgrounds in repeat/repeat mode, even if we need tiling in one dimension only. This has the unexpected side effect of opposite edge bleed, in the dimension which doesn't require tiling, when rasterized for hidpi devices (DSF causing Skia to sample across the tile boundary). Detect cases where tile repetition is not needed, and strength-reduce the shader tile mode accordingly. Also make Image::drawPattern() protected, as it is only used in subclasses. BUG= 673261 R=reed@google.com,fs@opera.com,schenney@chromium.org Review-Url: https://codereview.chromium.org/2582383002 Cr-Commit-Position: refs/heads/master@{#439529} [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/fast/borders/border-image-repeat-round-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/fast/borders/border-image-rotate-transform-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/fast/borders/border-image-side-reduction-expected.png [add] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/fast/hidpi/background-tile-bleed-expected.html [add] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/fast/hidpi/background-tile-bleed.html [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/platform/linux/fast/backgrounds/repeat/negative-offset-repeat-transformed-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/platform/linux/fast/borders/border-image-repeat-round-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/platform/linux/fast/borders/border-image-rotate-transform-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/platform/linux/fast/borders/border-image-side-reduction-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/platform/linux/virtual/gpu-rasterization/images/color-profile-border-image-source-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/platform/mac/fast/backgrounds/repeat/negative-offset-repeat-transformed-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/platform/mac/virtual/gpu-rasterization/images/color-profile-border-image-source-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/platform/win/fast/backgrounds/repeat/negative-offset-repeat-transformed-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-border-image-source-expected.png [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/Source/core/svg/graphics/SVGImageForContainer.h [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/Source/platform/graphics/Image.cpp [modify] https://crrev.com/a7e84a029b10a5a8c0b0faf4bda87e54187840fb/third_party/WebKit/Source/platform/graphics/Image.h
,
Dec 19 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Dec 12 2016