Issue metadata
Sign in to add a comment
|
Large background images with large background-position do not render or flicker
Reported by
oskarnib...@gmail.com,
Dec 23 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Visit Codepen (or) 2. Animate a substantially long image to over -10000px background-position-x 3. What is the expected behavior? Should not flicker in chrome (refer to recordit to see how firefox and safari handle it) What went wrong? Hi All, So it looks like I discovered a bug with chrome dealing with large image animations on background-url and background-position properties. For reference, here is a video of the bug (http://recordit.co/6z4tvYDrle) [chrome is bottom and top left, with safari and firefox being top right and bottom right respectively], and a codepen to experiment with various attributes (http://s.codepen.io/raksonibs/debug/xReBgy)(http://codepen.io/raksonibs/debug/xReBgy). You can see the image begins to flicker at a certain background-position property that spans past the image length. This is incredibly frustrating and creates a fairly bad experience for a user (this is a contrived example, but the reason for the background position sliding is valid in the application being built). Anyone have any idea? You can see in the codepen a lot of commented out code to reference some solutions I tried with no avail? Thanks, Oskar Did this work before? Yes Not sure, but I believe I handled larger/longer images in the past Does this work in other browsers? N/A Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.11.5 Flash Version: Shockwave Flash 24.0 r0 Please, this has been bugging me for over five days.
,
Dec 27 2016
Not sure if blink or cc.
,
Dec 27 2016
Reproduced on Mac M-57 Canary. I am pretty sure that this is due to pixel rounding issues. The flash is when we are rounding badly and landing outside the background image, or something like that. More investigation is required. I'd be willing to bet that the bisect lands on one of my patches affecting rounding for background image painting.
,
Dec 27 2016
,
Dec 29 2016
Able to reproduce this issue on Mac 10.12.2 on chrome stable version 55.0.2883.95 and also in current canary version #57.0.2964.0 Test Url:http://s.codepen.io/raksonibs/debug/xReBgy Issue is broken between in M52 & M53. Bisect Info: =========== Good build : 52.0.2743.0, Revision Range -394939 Bad build : 53.0.2744.0, Revision Range -395221 =========================================== After executing the bisect script(old), Unable to find the Change logs because bisect script has given all good builds =========================================== On manually looking at CL's between Good and bad builds. The suspecting Change Log is : ----------- https://chromium.googlesource.com/chromium/src/+/f3a9e63578aff4d5c814a5bb374665a4a0812834 From the above CL suspecting the below change --------------------------- Review-Url: https://codereview.chromium.org/1950243005 ymalik@- Could you please look into this issue, if it's related to your change? if not could you please help us to reassign this issue to the right owner.
,
Dec 29 2016
I'm not really trusting that bisect because none of the commits seem particularly relevant. Of them all, the most likely is https://chromium.googlesource.com/chromium/src/+/e0b9936e67197c642cf2eb165b09808779067b96 because it deals with large image decode size limits, but it appears to just be plumbing.
,
Jan 19 2017
,
Jan 31 2017
It seems to only happen with GPU raster enabled. In fact, when I disable the image hijack canvas and pass this code to skia directly, I get a crash: Received signal 11 SEGV_MAPERR 000000000000 #0 0x7ff738953087 base::debug::StackTrace::StackTrace() #1 0x7ff738952c0f base::debug::(anonymous namespace)::StackDumpSignalHandler() #2 0x7ff73867e330 <unknown> #3 0x7ff7376218ea GrContextPriv::makeWrappedSurfaceContext() #4 0x7ff737621a93 GrContextPriv::makeDeferredSurfaceContext() #5 0x7ff73765006a GrYUVProvider::refAsTexture() #6 0x7ff7374ab2f7 SkImageCacherator::lockTexture() #7 0x7ff737628fab GrImageTextureMaker::refOriginalTexture() #8 0x7ff73764cec9 GrTextureMaker::refTextureForParams() #9 0x7ff7374ab555 SkImageCacherator::lockAsTexture() #10 0x7ff73755b4d7 SkImage_Generator::asTextureRef() #11 0x7ff73755cc26 SkImageShader::asFragmentProcessor() #12 0x7ff737710e93 skpaint_to_grpaint_impl() #13 0x7ff737710d08 SkPaintToGrPaint() #14 0x7ff737707515 SkGpuDevice::drawRect() #15 0x7ff73741d6f7 SkCanvas::onDrawRect() #16 0x7ff7374dc21d SkMiniPicture<>::playback() #17 0x7ff737423b7e SkCanvas::drawPicture() #18 0x7ff7352b705d cc::DrawingDisplayItem::Raster() This happens right when the image wraps around. That is, the last frame I see before the crash is the end of the jpg that is scrolling. It is the same last frame I see before it becomes blank with the image hijack canvas enabled. So, something is going wrong with displaying the end and the start of that image. Note that it's >17,000 wide so the gpu image cache is unlikely to be handling this. We're likely to be handing this to Skia directly for tiling. bsalomon@, can you take a look? Note that it seems to work fine without GPU raster.
,
Jan 31 2017
One reason we may get a crash w/ we send images directly to Skia (without CC intercepting) is because Skia uses the YUV path in that case, so the logic will be a little different. The crash / disappearing image happen at the same point, so this seems like two different manifestations of the same bug.
,
Jan 31 2017
(note that I was able to reproduce this on Linux with gpu raster forced)
,
Jan 31 2017
Rob, do you think this crash is related to recent surfacecontext/proxy work?
,
Jan 31 2017
Looks to be.
,
Jan 31 2017
Although I don't think my changes can explain things all the way back to M55. They certainly could account for the crash in #8.
,
Feb 1 2017
The following revision refers to this bug: https://skia.googlesource.com/skia.git/+/77b3f32936dd069fa6a27f870b3b30035733d940 commit 77b3f32936dd069fa6a27f870b3b30035733d940 Author: Robert Phillips <robertphillips@google.com> Date: Tue Jan 31 23:24:12 2017 Broaden checking of GrSurfaceProxy::MakeDeferred's return value We now expect MakeDeferred to baulk if the ultimate texture/rendertarget will not be instantiable. Added checks for MakeWrapped too since, technically, it too can baulk. BUG= 676753 Change-Id: I3e052ebf98303fc46124272082c10f303d89da27 Reviewed-on: https://skia-review.googlesource.com/7830 Reviewed-by: Brian Salomon <bsalomon@google.com> Commit-Queue: Robert Phillips <robertphillips@google.com> [modify] https://crrev.com/77b3f32936dd069fa6a27f870b3b30035733d940/src/core/SkSpecialImage.cpp [modify] https://crrev.com/77b3f32936dd069fa6a27f870b3b30035733d940/src/gpu/GrContext.cpp [modify] https://crrev.com/77b3f32936dd069fa6a27f870b3b30035733d940/src/gpu/text/GrAtlasGlyphCache.cpp
,
Feb 1 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f2b188baeb2938427bf58b6ff6b61840f325055b commit f2b188baeb2938427bf58b6ff6b61840f325055b Author: skia-deps-roller <skia-deps-roller@chromium.org> Date: Wed Feb 01 16:06:19 2017 Roll src/third_party/skia/ d689f7a53..77b3f3293 (2 commits). https://skia.googlesource.com/skia.git/+log/d689f7a5313a..77b3f32936dd $ git log d689f7a53..77b3f3293 --date=short --no-merges --format='%ad %ae %s' 2017-01-31 robertphillips Broaden checking of GrSurfaceProxy::MakeDeferred's return value 2017-02-01 robertphillips Add test for proactive proxy-creation failure BUG= 676753 ,687174 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=halcanary@google.com Review-Url: https://codereview.chromium.org/2662413003 Cr-Commit-Position: refs/heads/master@{#447524} [modify] https://crrev.com/f2b188baeb2938427bf58b6ff6b61840f325055b/DEPS
,
Jan 2 2018
We've lost the test image and patches have landed. Closing it as fixed. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by nyerramilli@chromium.org
, Dec 23 2016