Issue metadata
Sign in to add a comment
|
Canvas fonts render incorrectly when area of canvas is <= 65536px
Reported by
andrew.s...@intellitect.com,
May 3 2017
|
||||||||||||||||||||||||
Issue description
Chrome Version : 58.0.3029.96
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Firefox 50.1: OK
IE 11: OK
Chrome 57.0.2987.133: OK
What steps will reproduce the problem?
File with minimal reproduction attached. Dimensions of the canvas in the file are around 256x256, but this happens with other dimensions, too - my real-world case happened to break around 444x148 pixels.
What is the expected result?
Fonts should render the same in both canvases.
What happens instead of that?
The canvas with an area of 65536 pixels renders as bold, while the slightly bigger canvas (256*257) renders correctly at normal font weight.
Please provide any additional information below. Attach a screenshot if
possible.
UserAgentString: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36
,
May 4 2017
Able to reproduce the issue on Windows 10, mac 10.12.4 and Ubuntu 14.04 using latest canary #60.0.3088.3, but unable to reproduce the issue on chrome reported version #58.0.3029.96. Bisect Information: ===================== Good build: 60.0.3081.0 Revision(467177) Bad Build : 60.0.3082.0 Revision(467534) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/f91ad00d0d78fe00a5d1ca4fc50ace6cd63718a7..4166ab857753a66e9ba6aea475ada0f14b0971d8 From the above change log suspecting below change Review url: https://codereview.chromium.org/2844483003 ericrk@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Adding label ReleaseBlock-Stable as it seems to be a recent regression. Thanks...!!
,
May 4 2017
,
May 4 2017
,
May 4 2017
It's somewhat odd that enabling GPU raster would affect canvas rendering. Is it possible that it changes something about how canvas content gets rendered (e.g. display list canvas gets enabled/disabled when GPU raster is on).
,
May 4 2017
My change shouldn't have any impact on Ubuntu (GPU raster is still disabled there). Given that this repros on Ubuntu, I'm guessing something else is causing this. Will re-bisect.
,
May 5 2017
Issue is not reproducible on OS-Linux.
,
May 5 2017
Ok, this is definitely triggered by GPU raster. Guessing it has to do with displaylist canvases - they're probably always enabled, but when we trigger GPU raster they rasterize using the GPU, leading to different results. It's a bit weird, as all canvas uses GPU, if I recall correctly, so I need to figure out why the display list canvas would rasterize differently.
,
May 22 2017
ericrk@ Since this issue marked as "RB_Stable" label, Could you please provide a latest update on this issue. Thank You...
,
May 25 2017
Display list canvas uses an intermediate SkPictureImageFilter to ensure that it renders at canvas size, irrespective of zoom. This has some effect on font rendering (e.g., there was a recent issue with LCD text on opaque canvases that was fixed by bumping to non-display-list canvas). Might be related.
,
May 31 2017
,
Jun 5 2017
Thanks for the suggestion senorblanco@, will look into this a bit more.
,
Jun 5 2017
I think these issues were one in the same. A quick bisect shows that this bug if fixed by https://chromium.googlesource.com/chromium/src/+/ee1c820d0133c0536a55b5a0aaf808a97c471bde
,
Jun 5 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, May 3 2017