Black graphical glitches/boxes when viewing documents with PDF.js
Reported by
imtony...@gmail.com,
Jul 21 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Have several Chrome tabs open 2. Visit www.box.com/cookieswitch/amsterdam/enable 3. Visit https://darth.app.box.com/s/ituq2a74l6afrfo40s5a6tbresa9bt3n 4. Let document load slowly, scroll up & down for a bit 5. Observe black boxes/glitches sometimes appear when going back and viewing other tabs & scrolling up & down What is the expected behavior? No black boxes/glitches - performance of one tab seems to be affecting performance in other tabs What went wrong? Black boxes/glitches in some other windows like: http://screencast.com/t/llr6f3PJ9 Black boxes will also sometimes appear on the page with a PDF.js viewer running Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 52.0.2743.82 Channel: stable OS Version: OS X 10.11.5 Flash Version: Shockwave Flash 22.0 r0 This issue seemed to happen very frequently around Chrome 48/49 and now much less frequently. Similar Chrome report I found: https://productforums.google.com/forum/#!topic/chrome/VXoAbUygYdM Other instances of the black boxes/glitches happening: http://imgur.com/a/SkOOw I also filed an issue with the Mozilla PDF.js team, and they suggested filing here since this is a Chrome-specific issue. PDFJS issue: https://github.com/mozilla/pdf.js/issues/7497
,
Jul 21 2016
Also seems to happen when you resize the page that causes repaints.
,
Jul 22 2016
imtonyjin@, you say this is less frequent than it once was. Roughly how often is this happening to you? Is there any way you can always make it happen? And I'm sure the GPU team will ask you to paste in the contents of chrome://gpu/ into a comment here. There's no doubt lots of users see this or have seen it. The old forum posts (late 2015) strongly suggest that Slimming Paint was at fault, although it's a bit hard to see why. I can't reproduce thus far. It obviously takes a long time to render the content from https://darth.app.box.com/s/ituq2a74l6afrfo40s5a6tbresa9bt3n (long base pair sequences, right?), but I'm getting the background color as expected when it's trying to paint the enormous number of text spans. I can't help thinking that GPU textures are being disposed due to memory pressure and not recreated when they are visible again. Either that or we are losing invalidations somehow or losing display list content. Adding appropriate components.
,
Jul 22 2016
Attached chrome://gpu output priyajeet & I can somewhat reliably reproduce by doing: 1. https://box.com/cookieswitch/amsterdam/enable (must visit this site first to enable a feature) 2. https://darth.app.box.com/s/ituq2a74l6afrfo40s5a6tbresa9bt3n 3. Letting the page render & scrolling to the next few pages 4. Open some other Chrome tabs, wait ~30s or so 5. Try going back to the tab with the link in #2 open and resizing the window 6. Observe graphical glitches sometimes in other Chrome tabs, sometimes in the tab with #2 open
,
Jul 23 2016
Thank you for providing more feedback. Adding requester "schenney@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 25 2016
Thanks. I'll try again, particularly Step 1.
,
Jul 27 2016
,
Jul 28 2016
,
Aug 4 2016
crbug.com/623375 seems to have reproduction steps that result in a crash, confirming that this is an out of memory problem.
,
Sep 14 2016
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by priyajeet@chromium.org
, Jul 21 2016Labels: OS-Windows