Chrome Version: 54.0.2810.0 (Official Build)Revision 24d606bb2a3e6290b97d9731c1dfd4dbfcb948e7-refs/heads/master@{#408294}(64-bit)
OS:Mac (10.10.5,10.11.4)
What steps will reproduce the problem?(1)Launch chrome and navigate to any pdf file for e.g https://msu.edu/~urban/sme865/resources/embedded_pdf.html OR https://msu.edu/~urban/sme865/resources/embedded_pdf.html(2)Click on Print button from top right and click on change button from destination
(3)Now click on page i.e outside print overlay 2-3 times,observe
Actual: Weird black line is seen on print preview after clicking on pdf page.
Expected: Weird black line should not be seen on print preview after clicking on pdf page.
This is a regression issue broken in 'M54' and will soon update other info.
If this is caused by one of my changes, it would be:
"""
Enable RenderPassDrawQuad promotion to CALayer.
"""
I'm having trouble reproducing this issue (tried two different machines, Canary and Chromium). Can people who have successfully reproduced share their configurations? (macOS version, GPU, etc.)
GN configuration for release build on a Mac Book Air running El Capitan Version 10.11.6:
is_debug = false
is_component_build = true
enable_google_now = false
enable_nacl = false
use_goma = true
dcheck_always_on = true
is_official_build = true
I checkout out the last commit above at 408294 and tried the PDFs in comment #2.
I could NOT repro this on Canary today.
I'm pretty sure this is related to Ganesh on Mac.
Observations:
1) I was only able to reproduce this on an Intel HD 5000 device, and only with a static Chromium build or Canary (not an official build).
2) Reverting my CLs related to RDPQ doesn't help. Neither does skau's printing CL, nor enne's "begin frame scheduling" CL.
3) The problem never reproduces with --disable-mac-overlays.
4) The flashing black lines that I see are always on tile borders. If you use --show-mac-overlay-borders, the flashing lines up perfectly with the tile borders.
5) I've never reproduced the problem with --disable-gpu-rasterization
The problem isn't deterministic, so I can't say for certain that it's Ganesh, but I tried the following:
a) Launch a problematic build with no flags. See flashing black line.
b) Launch with --disable-gpu-rasterization. Don't see problem.
Repeat (a) & (b) 3 times. Same results.
I know that Ganesh on Mac has issues with HD 3000 and HD 4000, so I wouldn't be surprised if HD 5000 was also problematic...
I'm able to repro. One thing I noticed is that repro wouldn't happen in HiDPI (retina) mode. Forcing my computer into non-retina mode (using a 3rd party util, RDM) allowed me to repro. Not an issue on MBA, but if anyone's trying to repro on a MBP this may help.
After digging further, this is not actually related to GPU raster, but to the tile size being used. It just happens that the tile size used in GPU raster hits this bug. If I switch SW raster to use GPU-Raster sized tiles, then this issue shows up there as well.
I'm able to repro on a number of configurations, assuming I disable HiDPI mode. This includes GeForce 650M, HD4000 and HD5300. Additionally, I was able to reproduce this quite a ways back (I repro'd with a June 1 build, then stopped), so this isn't likely a recent regression.
In the repro case, this issue shows up during an animation where we scale up the layer (and the IOSurfaces making it up). It appears that with certain sizes of IOSurfaces gaps are left between the surfaces when the layer is scaled up (see the attached picture).
We should check whether we have a rounding error that could lead to this. If not (and this is an OS issue), we may be able to modify the rounding used for tiles to pick sizes that avoid this. I was able to reproduce this issue at a number of tile sizes, but rounding to multiples of 32 appears to avoid the issue (we currently round to multiples of 4).
I'll look into this more tomorrow.
+ccameron in case he has any thoughts.
Discussed with ccameron@ - seems like we should eventually move to using more standard (square) tiles for GPU raster, but as this is a large change. The best option at the moment is probably to round tile sizes to a larger value and try to avoid the rounding error. Local testing seems to indicate that 32 (but not 16) is enough to avoid this issue. From looking at the IOSurface APIs, there doesn't appear to be a required alignment.
SW uses 64 pixel alignment and has never been seen to hit this issue, so we could chose 64 as well.
Could someone confirm the layer positions for this content? We've seen issues related to huge layer offsets which cause gaps in tiles due to numeric errors in floating point math in the compositor (Issue 623198).
Here's a simpler repro case - will trigger the issue (or a very similar one) with both SW and GPU raster.
Oddly, this seems impacted by solid color vs contentful tiles - not sure if this is part of the issue, or if it just changes things slightly and hides the issue in this repro case.
So I don't know how CoreAnimation works but I have a hypothesis that both GLRenderer and CA are prone to numerical errors in computing tile coordinates whenever we have either huge coordinates, or funky scales with complex FP32 representations.
To qualify funky, something that takes most of 24bits of FP32 number's mantissa. This doesn't happen for example with page zoom which is mostly to certain values: 1.0, 1.1, 1.25, 1.5, 1.75, etc..
What I notice on the msu.edu page is the offending layer has a scale transform of 1.019786f or 0x3f828859 as HEX. This is a "funky" scale with 24 full bits of significant data in the mantissa, very prone to numerical errors. We could truncate (round) these to make them less funky.
Similarly rounding tile coordinates helps too.
Here's a test...
A is the "bottom" coordinate of tile "i".
B is the "top" coordinate of tile "i+1".
A and B should match.
tile_height = 425.000000 (000001A9)
scale = 1.019786 (3F828859)
i0 A 43D8B45C B 43D8B45C
i1 A 4458B45C B 4458B45C
i2 A 44A28745 B 44A28745
i3 A 44D8B45C B 44D8B45C
i4 A 450770BA B 450770B9 <<< DIFFERENT
i5 A 45228744 B 45228745 <<< DIFFERENT
i6 A 453D9DD0 B 453D9DD0
i7 A 4558B45C B 4558B45C
i8 A 4573CAE8 B 4573CAE7 <<< DIFFERENT
i9 A 458770B9 B 458770B9
tile_height = 448.000000 (000001C0)
scale = 1.019786 (3F828859)
i0 A 43E46E9C B 43E46E9C
i1 A 44646E9C B 44646E9C
i2 A 44AB52F5 B 44AB52F5
i3 A 44E46E9C B 44E46E9C
i4 A 450EC522 B 450EC521 <<< DIFFERENT
i5 A 452B52F4 B 452B52F5 <<< DIFFERENT
i6 A 4547E0C8 B 4547E0C8
i7 A 45646E9C B 45646E9C
i8 A 45807E38 B 45807E38
i9 A 458EC522 B 458EC521 <<< DIFFERENT
tile_height = 448.000000 (000001C0)
scale = 1.019785 (3F828850)
i0 A 43E46E8C B 43E46E8C
i1 A 44646E8C B 44646E8C
i2 A 44AB52E9 B 44AB52E9
i3 A 44E46E8C B 44E46E8C
i4 A 450EC518 B 450EC518
i5 A 452B52EA B 452B52E9 <<< DIFFERENT
i6 A 4547E0BA B 4547E0BA
i7 A 45646E8C B 45646E8C
i8 A 45807E2F B 45807E2F
i9 A 458EC518 B 458EC518
tile_height = 448.000000 (000001C0)
scale = 1.019775 (3F828800)
i0 A 43E46E00 B 43E46E00
i1 A 44646E00 B 44646E00
i2 A 44AB5280 B 44AB5280
i3 A 44E46E00 B 44E46E00
i4 A 450EC4C0 B 450EC4C0
i5 A 452B5280 B 452B5280
i6 A 4547E040 B 4547E040
i7 A 45646E00 B 45646E00
i8 A 45807DE0 B 45807DE0
i9 A 458EC4C0 B 458EC4C0
Hmm - I think the secondary repro case I posted earlier is likely a different (but similar) bug, still a rounding error, but in this case just showing a difference between solid-color and regular tiles.
Please try to merge your change to M53 branch 2785 today before 4:00 PM PT on Monday so we can pick it up for next week LAST M53 beta release. Thank you.
A friendly reminder that M53 Stable is launching VERY soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP (before 5:00 PM PT, Tuesday) so we can take it for this week LAST Beta release for Desktop. Thank you!
Note: Merge has to happen by Friday, August 26th, 5:00 PM PST in order to make into the desktop Stable final build cut.
Tested the same on mac 10.11.6 chrome version 53.0.2785.80 - Weird black line is not seen on print preview after clicking on pdf page
Please find the screencast
Adding TE verified labels
Comment 1 by vku...@etouch.net
, Jul 28 2016Labels: hasbisect
Owner: ekaramad@chromium.org
Status: Assigned (was: Unconfirmed)
2.4 MB
2.4 MB Download
3.4 MB
3.4 MB Download