Closed Bug 1447035 Opened 4 years ago Closed 4 years ago

JQPlot graph not painting anymore (e.g. prior electricity usage at )


(Core :: Graphics, defect)

61 Branch
Not set



Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 --- fixed
firefox61 --- fixed


(Reporter: dholbert, Assigned: lsalzman)



(Keywords: regression)


(7 files)

(Sadly I don't have public STR I can post for this, because the affected site is behind a login wall. If any graphics developers are interested in poking at this, I'm happy to share my username/password privately.)

 0. Have a "Rainforest Eagle" electricity-monitoring device.
 1. From an Android phone, log in at
 2. Click the "History" button on the right.

History usage should get painted onto graph.

There's just an empty graph -- the usage isn't painted onto it.

The usage seems to be drawn into the following canvas element on the page:
<canvas width="529" height="223" style="position: absolute; left: 41px; top: 10px; display: block;" class="jqplot-series-canvas"></canvas>
So far I've only been able to reproduce with Nightly on Android (on two different phones, including in "new guest session" so it's not profile-specific).

I tracked down when it started with mozregression:

Hence, marking as regression from bug 1444506.
Version: 57 Branch → 61 Branch
Here's the expected rendering (taken in Firefox beta 60).  (Note that I'm using an internal IP address for convenience, to view my device's web UI more directly, hence the 192.168.* in the URL bar here.)
and here's the screenshot of the actual rendering, in latest Nightly.
Also, I can reproduce on Linux Desktop Nightly if I enable SkiaGL by setting the following prefs to true:
 layers.acceleration.force-enabled  (have to "create" this pref - it's not listed in about:config by default)

(thanks lsalzman)
Also worth noting: before the regression, the graph would occasionally only partly paint. There's an animation which starts at the left edge and fills in usage data left-to-right, and sometimes that'd stop say 80% of the way across (and e.g. switching tabs wouldn't help, so it wasn't an invalidation bug).  But when that happened, a reload would usually fix it.

After the regression, none of the usage data paints at all.

(Just noting because it seems possible the new issue is a more severe form of the old issue.)
Summary: Graph not painting anymore, for prior electricity usage at → JQPlot graph not painting anymore (e.g. prior electricity usage at )
Attached file testcase 1
Here's a standalone testcase (which uses the two attached JS files), based on this set of demos that Lee found (which reproduce the bug):

In a profile where I've set the prefs noted in comment 3, no dots are displayed on the graph in this testcase.
Attached file testcase 2
Another version of this bug (or at least with the same prefs + regression range): every canvas at (after the first blank one) renders the same contents, incorrectly -- usually they all render the final example's circular gradient.

Here's a testcase reduced from that page.
EXPECTED RESULTS: "Hello World" in first canvas, purple in second canvas.
ACTUAL RESULTS: Purple in both canvases.
I tracked this down to a bug in Skia's new explicit GPU resource allocation feature, which I had already disabled on macOS due to very evident bugs there when I was working on the Skia update. But apparently the feature was broken on all other platforms as well, so the solution here has been to just disable the explicit GPU resource allocation everywhere for now. I posted the patch as a follow-up in bug 1444506.

Daniel Holbert confirmed a version of this fix resolved the problems with his test-cases, so once that lands in the follow-up patch we can mark this bug as resolved.
Assignee: nobody → lsalzman
Closed: 4 years ago
Resolution: --- → FIXED
Thanks for the quick work on this!

Could you add an automated testcase (perhaps based on the attached 'testcase 2') that would've caught this & could catch this if it regresses?
Flags: needinfo?(lsalzman)
Flags: in-testsuite?
Skia 66 was uplifted to Beta with this fix included.
Target Milestone: --- → mozilla61
This is just a simplified version of your two canvas test-case to make it suitable for comparison with a ref in a reproducible manner. It draws two solid colored gradients, one in each canvas, of different colors, filling the entirety of each canvas. Ideally, it should match the ref whose canvases' background-colors has been set with nothing drawn into those canvases.

If it doesn't match, well, something has gone terribly wrong somewhere. In any case, it fails without my bug fix, and passes with my bug fix, which is what is important. :)
Flags: needinfo?(lsalzman)
Attachment #8961219 - Flags: review?(dholbert)
Comment on attachment 8961219 [details] [diff] [review]
test to verify that multiple accelerated canvases on the same page work

Review of attachment 8961219 [details] [diff] [review]:


r=me with one nit:

::: layout/reftests/canvas/1447035-1.html
@@ +4,5 @@
> +function fillCanvas(gradColor) {
> +    var c = document.getElementById(gradColor + 'Canvas');
> +    var ctx = c.getContext("2d");
> +    // Create gradient
> +    var grd = ctx.createRadialGradient(75,50,5,90,60,100);

s/gradient/solid-color "gradient"/

Or some similar clarification.  (It's kind of confusing right now, since our "gradient" is all the same color -- i.e. we're using the same color at both color stops, so there's no gradation.  It's helpful if the comment kind of points that out somehow -- this wasn't obvious to me at first, so I was confused at how we were ending up with a solid-color rect.)
Attachment #8961219 - Flags: review?(dholbert) → review+
Pushed by
test to verify that multiple accelerated canvases on the same page work. r=dholbert
Pushed by
follow-up - reftest comment clarification. r=me
You need to log in before you can comment on or make changes to this bug.