I suspect it's more likely 363805 though it's quite possible the new behavior is "technically" correct (and the site is at fault). Assigning to Levi to decide.
The issue is indeed in snapping then pulling the sprite out of the large image. It works fine at 100% because we probably don't snap there, but at higher zoom we see the artifacts.
This is not a release blocking issue and a fix is likely to be difficult. Current ToT does not fix the issue, so further digging is required.
Test case attached.
The issue is related to the long sequence of rounding and scaling that are done to render the image. Ideally we would refactor everything to round just once and scale just once.
Specifically, GraphicsContext asks for this src and dest rect:
GC::drawImage src: 33.916664 566.480408 30.250000 25.459793
GC::drawImage dest: 19.000000 11.000000 33.000000 28.000000
They are about right, and reflect the right zoom scale and pretty much the right location in the sprite map. But by the time we get the decoded image back in image_hijack_canvas.cc, we are using
src 33.916664 566.480408 30.250000 25.459778
Rect-Rect Matrix: [ 1.0909 0.0000 -18.0000][ 0.0000 1.0998 -612.0004][ 0.0000 0.0000 1.0000]
Total Matrix: [ 1.0909 0.0000 -18.0000][ 0.0000 1.0998 -612.0004][ 0.0000 0.0000 1.0000]
src rect offset -33.000000 -566.000000
scale 1.093750 1.115385
adjustedSrc 1.002601 0.535839 33.085938 28.397444
dst 19.000000 11.000000 33.000000 28.000000
Note that once we're done, the adjusted source rect should be ideally be 33 x 28 in size at 0,0 in location, I think. Regardless, we're somehow getting the wrong pixels from the cache. This may be triggered by changes to rounding in background image painting, or may be due to changes in image caching.
This issue is Pri-1 but has already been moved once. Lowering the priority and moving to the next milestone.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
The underlying problems is due to the change to compositor caching of images, which was an enormous change with other benefits and hence not possible to reasonably revert.
It may been that one of my changes to background image pixel snapping triggered it, but reverting any of those will cause other problems. I can try fixing it in the background geometry code, but the first time I tried it seemed to be impossible because the compositor cache did not give the requested pixels. So we'd be adding a hack to work around bad behavior in the compositor cache.
The long term correct fix, which would also fix https://bugs.chromium.org/p/chromium/issues/detail?id=608874 and https://bugs.chromium.org/p/chromium/issues/detail?id=608303, is reworking the compositor cache to better handle subsets of images (aka sprite maps)
Rechecked the above issue on OS: Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.12.6,10.13.1,10.13.3) with latest canary chrome version: 66.0.3329.0 and the issue is still reproducible.Kindly refer attached screen cast for reference.
Comment 1 by adha...@etouch.net
, Mar 14 2016