See #1732 for the test case image/code.
The used image is attached here:

I can repro it on Linux/Intel.
Webrender @ a884e676449e5b41669cd6de51af14e70cbe3512 ("a884e676449e5b41669cd6de51af14e70cbe3512")
Nightly 58 x64 20171005100211 de_DE @ Debian Testing (KDE / Radeon RX480)
gpu process + layers force accel + webrender + webrendest
This wasn't completely fixed:
The thin grey line can come back if
(The thin grey line was always visible yesterday, so I am sure I got the patch with the last webrender update.)
@Darkspirit I don't see it in the links you provided. Could you explain your test case a bit more?
Comment 5 + video in comment 6
https://bugzilla.mozilla.org/show_bug.cgi?id=1401665#c5
(Either it's still this bug, or it's another case of #1805. Or both are the same.
Disclaimer: I do not understand what I'm talking about.)
There is a new testcase from @mstange in https://bugzilla.mozilla.org/show_bug.cgi?id=1401665#c7
I can reproduce the remaining black line with this testcase at default zoom on a 2x display, and with 2x zoom on a 1x display.
(Thank you!)
YAML version of the testcase:
---
root:
items:
-
bounds: [0, 0, 0, 0]
"clip-rect": [0, 0, 0, 0]
"clip-and-scroll": 0
"backface-visible": true
type: "stacking-context"
"scroll-policy": scrollable
"transform-style": flat
items:
-
bounds: [0, 0, 2880, 1474]
"clip-rect": [0, 0, 2880, 1474]
"clip-and-scroll": 0
"backface-visible": true
type: rect
color: white
-
bounds: [0, 0, 2880, 1474]
"clip-rect": [0, 0, 2880, 1474]
"clip-and-scroll": 0
"backface-visible": true
type: clip
id: 5
"content-size": [2880, 1474]
-
"clip-rect": [0, 0, 2880, 1474]
"clip-and-scroll": 5
"backface-visible": true
type: "scroll-frame"
id: 2
"content-size": [2880, 1474]
bounds: [0, 0, 2880, 1474]
-
bounds: [0, 0, 2880, 1474]
"clip-rect": [0, 0, 2880, 1474]
"clip-and-scroll": 2
"backface-visible": true
type: clip
id: 3
"content-size": [2880, 1474]
-
bounds: [0, 0, 2880, 1474]
"clip-rect": [0, 0, 2880, 1474]
"clip-and-scroll": 3
"backface-visible": true
type: rect
color: white
-
bounds: [0, 0, 0, 0]
"clip-rect": [0, 0, 0, 0]
"clip-and-scroll": 3
"backface-visible": true
type: "stacking-context"
"scroll-policy": scrollable
transform: [-0.70710677, 0.70710677, 0, 0, -0.70710677, -0.70710677, 0, 0, 0, 0, 1, 0, 441.91882, 235, 0, 1]
"transform-style": flat
items:
-
bounds: [2, 2, 266, 266]
"clip-rect": [2, 2, 266, 266]
"clip-and-scroll": 3
"backface-visible": true
type: clip
id: 4
"content-size": [266, 266]
-
bounds: [2, -243, 202, 288]
"clip-rect": [2, 0, 202, 45]
"clip-and-scroll": 4
"backface-visible": true
image: "res/1507742000-img-97.png"
"stretch-size": [202.16667, 287.26666]
"tile-spacing": [0, 0]
-
bounds: [0, 0, 270, 270]
"clip-rect": [0, 0, 270, 270]
"clip-and-scroll": 3
"backface-visible": true
type: border
width: 2
"border-type": normal
color: 0 0 255 1.0000
style: solid
id: [1, 1]
pipelines: []
res/1507742000-img-97.png is still the same image as above.
Thanks @mstange !
These two test cases are rendering properly for me now, but mstange's yaml test case is still showing some sampling artifacts (I edited it to fix an invalid id 1 which is now reserved for root scroll nodes.)
Up to date screencast: https://bugzilla.mozilla.org/show_bug.cgi?id=1401665#c10
@nical interestingly, both of those links still fail for me.
They are fixed once we remove the mod from this line:
vec2 repeated_uv = mod(local_uv, uv_size) + vUvBounds.xy;
I've been looking at this some more, experimenting with a few hacks, and I came to conclusion that this is a downstream issue (after talking to @aosmond ). The contract with WR is that for non-repeated image the stretch size needs to be equal to the local size. This isn't the case for our image:
(
item: Image((
image_key: ((74), 1),
stretch_size: (217.14285278320313, 308.5714416503906),
tile_spacing: (0, 0),
image_rendering: Auto,
alpha_type: PremultipliedAlpha,
)),
clip_and_scroll: (
scroll_node_id: Clip(1, (1, 81)),
clip_node_id: Some(ClipChain((1, (1, 81)))),
),
info: (
rect: ((2, -261), (217, 309)),
clip_rect: ((2, 0), (217, 48)),
is_backface_visible: true,
tag: None,
),
),// [8]
So WR sees it as repeated image (on Y axis) and treats it accordingly.
The fix should supposedly go to PrepareImageLayer.
I commented on the BZ issue -- it doesn't seem like this is still reproducable (at least, I wasn't able to)
https://bugzilla.mozilla.org/show_bug.cgi?id=1401665#c16 and
"Reddit vote buttons have glitches at the edges" are still reproducible.
Even with SW-WR, but not with Basic Layers and Chromium.
Most helpful comment
I've been looking at this some more, experimenting with a few hacks, and I came to conclusion that this is a downstream issue (after talking to @aosmond ). The contract with WR is that for non-repeated image the stretch size needs to be equal to the local size. This isn't the case for our image:
So WR sees it as repeated image (on Y axis) and treats it accordingly.
The fix should supposedly go to PrepareImageLayer.