This is a problem with pixel snapping the tile size. It's clear that when we have fractional tile sizes computed with the background-size: calc(100% / 10); we snap the tile to integral size, leaving a 0 - 9 pixel residue when we tile, that snaps back to 0 every time the calc result ends up a integer.

For a non-intrinsic size image like linear gradients, we should allow non-integer tile sizes. That a huge mess to deal with, however, because it would require 2 code paths.

However, if we're resampling images anyway, and not using the scaling methods that require integral rectangles, there's no reason to force integral rects.

fmalita@, can you summarize your understanding of which scaling methods need integral rectangles?

It's not obvious to me what the bug is: I get the same result (narrow vertical gradient stripes) in both Chrome & FF.

To reproduce you need to resize the window dynamically. I can produce a better test, methinks.

Ah, I see it now.

None of the scaling methods *require* integral sizes, but there are some related considerations:

a) Internally, both Skia and CC's ImageDecodeController cache the results of HQ upscaling - and the cached images are obviously int-sized.  But the residual int-snapping transform is accounted for and compensated at draw time (via a secondary bilerp filter).  This has some quality implications, but should produce contiguous results for subpixel transitions (at least in theory - in practice there are some minor issues when switching between int-sized cache entries).

b) Drawing unaligned image tiles discretely can introduce seaming artifacts (discrete edge AA => backdrop bleed).  Fortunately this isn't an issue when using shaders for tiling, as we do.

So yeah, from a rasterization perspective tiles don't have to be pixel-aligned.  The mechanisms we use should produce correct results regardless, but I suspect quality may suffer in some cases (HQ scaling + secondary bilerp pass => lower contrast;  not sure whether we currently use HQ scaling for background tiling).

Any news? This is very annoying bug. 

Did you actually try it? Seem fixed to me, using the initial example, looking on Mac on Chrome Canary (M-70).

I probably fixed this when I made tile size fractional for background images.

this bug causes serious issues on chrome, and especially mobile chrome: background gradients are "cut off" when desktop users resize their window, and worse yet on mobile, whenever the user scrolls (causing chrome's address bar to "tuck away"), chrome is failing to update the background following this viewport resizing, and so basic scrolling leaves a gradient failure visible on the bottom of the page..

the following standard css technique suffers this problem (the only workaround seems to be avoiding bg gradients):

    html, body { height: 100%; background: fixed no-repeat linear-gradient(to bottom, white, black); }

in other words, when the user resizes the window larger, or scrolls in mobile chrome (address bar tucks, causing a viewport resize), the bug manifests as the gradient does not update to expand, leaving a "cut off" appearance

i noticed this bug doesn't happen on firefox, but i have seen it in chrome for awhile, which has been surprising to me as it seems so conspicuous and easily reproducible

interestingly i noticed the bug did not manifest when i attempted to reproduce it on codepen.io -- perhaps something about the frames being used innoculated the preview pane against this resizing issue

here i have attached two images which demonstrate the bug on a website i am working on

first image -- webpage appears normal

second image -- user scrolls down, address bar slides up and away (increasing the viewport's actual height), and the bug manifests as a bar along the bottom of the screen where the gradient no longer stretches to meet the viewport's height

note, the same bug appears reproducible on desktop by resizing the window vertically larger

my apologies if i am describing a different bug here, it's not entire clear to me.. a discussion on stackoverflow brought me here https://stackoverflow.com/questions/36675890/chrome-not-updateing-background-size-gradient-properly-on-resize

cheers

Deleted: Screenshot_20180828-110235_Chrome.jpg 1.1 MB

	Screenshot_20180828-110235_Chrome.jpg 1.1 MB View Download

Deleted: Screenshot_20180828-110309_Chrome.jpg 1.1 MB

	Screenshot_20180828-110309_Chrome.jpg 1.1 MB View Download

when i have the opportunity, i will test to see if this reproduces in chrome canary (i have been using stable)

yes i have just now confirmed, the bug still manifests on Canary on android, it remains reproducible

Fixed backgrounds are not supported on Android due to the high cost of rendering them. We can look into the desktop case, however.