Closed Bug 1347094 Opened 6 years ago Closed 6 years ago

Canvas drawImage bug with large images (results in a tiled and wrong scaled image)


(Core :: Graphics: Canvas2D, defect, P1)

52 Branch



Tracking Status
firefox52 --- fixed
firefox-esr52 --- fixed
firefox53 --- fixed
firefox54 --- fixed
firefox55 --- fixed


(Reporter: mail, Assigned: lsalzman)



(Whiteboard: [gfx-noted])


(2 files)

Attached image ffbug.png
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170307064827

Steps to reproduce:

Using Canvas + drawImage + scaling + a large image = buggy rendering output.

That happens since Firefox version 52 and as it seems only on OSX.
Firefox Beta (53) and Firefox Nightly (55.0a1) are affected as well.

Here a online test-case:

Just in case it's relevant - Chrome had the same bug in Chrome 54:

Actual results:

Test case results: the upper image is a normal <img> image and correct and the image below a <canvas> with the image drawn downscaled with drawImage into it.

Expected results:

Both images should look similar, not scaled and broken.
Attached a screenshot.
Component: Untriaged → Canvas: 2D
Product: Firefox → Core
Klaus, could you run the tool mozregression to narrow down a regression range in FF52, please.
See for details to install and use it.

Run the command "mozregression --good=51", then for each build launched by the tool, make the test and enter if the build is good or bad. After the run, copy here the final pushlog from the repository mozilla-inbound.
Flags: needinfo?(mail)
OS: Unspecified → Mac OS X
Nice tool - here it's output: 

 7:19.15 INFO: Narrowed nightly regression window from [2016-11-02, 2016-11-05] (3 days) to [2016-11-04, 2016-11-05] (1 days) (~0 steps left)
 7:19.15 Got as far as we can go bisecting nightlies...
 7:19.15 INFO: Last good revision: 8002299dfc3fb3b2c53e50e40a8e16f8dff2c3e7 (2016-11-04)
 7:19.15 INFO: First bad revision: a7c654513f2ffd9d9ef38fa2bf512b9e8dae3cdd (2016-11-05)
 7:19.15 INFO: Pushlog:

 7:19.15 INFO: Switching bisection method to taskcluster
 7:19.15 INFO: Getting mozilla-central builds between 8002299dfc3fb3b2c53e50e40a8e16f8dff2c3e7 and a7c654513f2ffd9d9ef38fa2bf512b9e8dae3cdd
 7:24.76 ERROR: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:590)

But is that error at end normal?
No, mozreg should switch to taskcluster and m-i repos after getting pushlog from m-c.

Can you retry with the command:
mozregression --good=2016-11-03 --bad=2016-11-06 --repo=mozilla-inbound

NB: if the initial boundary builds are not good or bad, just enlarge them by 1 day and retry.
Doesn't unfortunately work - the same error happens - here what happens:

macOS-Sierra:~ krpano$ mozregression --good=2016-11-03 --bad=2016-11-06 --repo=mozilla-inbound
You should use a config file. Please use the --write-config command line flag to help you create one.

 0:00.42 INFO: Getting mozilla-inbound builds between 2016-11-03 and 2016-11-06
 0:05.03 ERROR: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:590)

Btw - I had to install mozregression with the '--ignore-installed six' setting because of a six version problem. Could this be the reason?
(In reply to Klaus Reinfeld from comment #4)

> Btw - I had to install mozregression with the '--ignore-installed six'
> setting because of a six version problem. Could this be the reason?

It's a python error, probably because the SSL support is old with python 2.7. I think you need to update it with the "pip" command, see:
I'm running this on a stock OSX 10.12.3 with its stock Python 2.7.10 and there nothing of that works...
When trying to update Python's openSSL link show in your links there is always an 'Operation not permitted' error (seems to be related to the OSX sandboxing).

When trying the same on an older OSX 10.9.5 system with Python 2.7.5, the mozregression installation itself works without problems, but therefore running mozregression fails with that error:

'DistributionNotFound(req)  # XXX put more info here pkg_resources.DistributionNotFound: colorama==0.3.7'


Sorry, but I think I can't help here anymore, I'm no OSX or Python specialist and have no time to dig into the 
dependency hell of Python... 

Can't somewhere at Mozilla run it?
You would only need to enter this url:

and you would instantly see if it works or not - e.g. 'just seeing two times the same image or not'.

Best regards,
Andrei, could you find someone from QA on OSX (reporter is using OSX 10.12.3) to find a regression range in FF52.
Url to test is
Flags: needinfo?(mail) → needinfo?(andrei.vaida)
That said, when checking the pushlog from m-c in comment #2, I think the regression is due to bug 1309913.
Just as note - this doesn't seems to be OSX version depending. Due my tests this happens on all OSX versions I've tested (10.9.5, 10.11.6 and 10.12.3).

And one another note - Chrome had the SAME bug and there the problem was located in Skia - see here:

Maybe Firefox would only need to merge that fix or update its Skia library...
This is just a simple one-line backport of the upstream fix:

It was already cherry-picked for m55 which we used, but they cherry-picked it after we merged.
Assignee: nobody → lsalzman
Ever confirmed: true
Attachment #8847685 - Flags: review?(mchang)
This bug has been around since we updated to Skia m55 in FF 52. Since that affects pretty much all our releases, we'll just call bug 1299435 the source of the regression, though the bug could have existed before that (which is not terribly relevant at this point).

This affects all SkiaGL users, so at least Mac and Android by default.
Has Regression Range: --- → yes
Has STR: --- → yes
Depends on: 1299435
Flags: needinfo?(andrei.vaida)
OS: Mac OS X → All
Priority: -- → P1
Hardware: Unspecified → All
Whiteboard: [gfx-noted]
Attachment #8847685 - Flags: review?(mchang) → review+
Pushed by
fix SkiaGL canvas drawing of large images. r=mchang
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Comment on attachment 8847685 [details] [diff] [review]
fix SkiaGL canvas drawing of large images

Approval Request Comment
[Feature/Bug causing the regression]: bug 1299435, so affects 52+
[User impact if declined]: Broken drawing of large images in Canvas2D when using SkiaGL (Mac/Android).
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: no 
[List of other uplifts needed for the feature/fix]: just this
[Is the change risky?]: no
[Why is the change risky/not risky?]: This was fixed in upstream Skia several milestones ago already and was incorporated into Chrome as well.
[String changes made/needed]: none
Attachment #8847685 - Flags: approval-mozilla-release?
Attachment #8847685 - Flags: approval-mozilla-esr52?
Attachment #8847685 - Flags: approval-mozilla-beta?
Attachment #8847685 - Flags: approval-mozilla-aurora?
Comment on attachment 8847685 [details] [diff] [review]
fix SkiaGL canvas drawing of large images

Fix a broken drawing issue related to SkiaGL. Aurora54+ & Beta53+.
Attachment #8847685 - Flags: approval-mozilla-beta?
Attachment #8847685 - Flags: approval-mozilla-beta+
Attachment #8847685 - Flags: approval-mozilla-aurora?
Attachment #8847685 - Flags: approval-mozilla-aurora+
I tested today's nightly and everything is working correctly now.

Thanks for the great support and quick fixing!

Best regards, 
Setting qe-verify- based on Lee's assessment on manual testing needs (see Comment 14) and the fact that this fix has automated coverage.
Flags: qe-verify-
Comment on attachment 8847685 [details] [diff] [review]
fix SkiaGL canvas drawing of large images

let's get this in esr52 (default branch)
Attachment #8847685 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+
Comment on attachment 8847685 [details] [diff] [review]
fix SkiaGL canvas drawing of large images

looks safe enough, and is a new regression in 52, let's take this in m-r and the esr52 FIREFOX_ESR_52_0_X_RELBRANCH
Attachment #8847685 - Flags: approval-mozilla-release? → approval-mozilla-release+ (FIREFOX_ESR_52_0_X_RELBRANCH - 52.0.2)
You need to log in before you can comment on or make changes to this bug.