1126055 - SkiaGL canvas result differs from Skia canvas, Quartz, D2D, Cairo when clipping regions are involved

Status: RESOLVED WORKSFORME

(Core :: Graphics: Canvas2D, defect)

Description

[David Flanagan [:djf]]

If I define a clipping region in a canvas and then fill that region using globalCompositeOperation "copy", it works as expected in desktop Firefox, but if I try the same code on FirefoxOS or in Firefox for Android, the clipping region is ignored and the bounding-box of the path is cleared before filling.

There is a reduced test case online at http://djf.net/bug.html.

I'll attached the code, and also screenshots from desktop and mobile demonstrating how the rendering differs.

Comment 1

[David Flanagan [:djf]]

Attachment: test case

Comment 2

[David Flanagan [:djf]]

Attachment: test case rendered in desktop firefox

Comment 3

[David Flanagan [:djf]]

Attachment: test case rendered in FirefoxOS browser

Comment 4

[David Flanagan [:djf]]

Attachment: another test case with the same issue

This is another test case that produces exactly the same same bug. In this one, we don't use globalCompositeOperation=copy but instead do a clearRect with a clip region defined.

The clip region is not handled correctly and the entire bounding box of the triangle is cleared instead of just the triangle.

Again, it works correctly on desktop but fails on FirefoxOS and Android.

This testcase is online at djf.net/bug2.html

Comment 5

[David Flanagan [:djf]]

These are admittedly kind of weird test cases: I could acheive the desired effect without a clipping region or clearRect or globalCompositeOperation.

The reason I care is that I need to draw with a translucent black color instead of blue, and I need to ignore the pixels that are currently drawn in the canvas. So I either need to be able to clear the region to transparent black with clearRect() or I need to be able to use globalCompositeOperation=copy.

This is for a color picker web component I'm developing in bug 1123829.

Comment 6

[David Flanagan [:djf]]

Turns out that I've got an old version of Firefox Aurora (gecko 14) on my android phone...  These bugs do not appear in that version. But they do appear in the current Android Firefox Beta (gecko 36). So this is a regression.

Comment 7

[David Flanagan [:djf]]

The bug is also present in the current (gecko 35) Firefox for Android. I haven't tried looking at different versions of FirefoxOS to see how far back the regression goes on that platform.

Milan: is this something that your team works on, or do you know who does work on this?

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

I think is a difference (bug) between Skia GL canvas (used on Android and B2G) and the other backends we use on the desktop (Quartz, D2D, SW, and Skia SW).  Do you get the result you're looking for if you set gfx.canvas.azure.accelerated to false (the default is set in https://dxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#939)?

Comment 9

[David Flanagan [:djf]]

Milan: I didn't try changing that pref, but I found that if I add {willReadFrequently:true} to the canvas.getContext() call then the bug goes away. I suspect that acheives the same thing.

So I think I've got a workaround for my color picker element, and you've got confirmation that this bug is in the accelerated backend used on mobile.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Yes, setting willReadFrequently to true currently disables SkiaGL (as it's more expensive when the readback is part of the picture), so you end up with the Skia SW canvas, which has the results that match the rest.  I'll mutate the bug to track what's left.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

CC-ing Jeff in case one of the not-yet-upstreamed patches we have for Skia fixes this.