862787 - Four reftest failures on b2g emulator after layers refactoring

Status: RESOLVED INCOMPLETE

(Core :: Graphics: Layers, defect)

Description

[Andrew Halberstadt [:ahal]]

There are still four reftest failures (with b2g only) that started when the layers landing happened:
layout/reftests/reftest-sanity/647192-1.html
image/test/reftest/bmp/bmp-1bpp/bmp-size-1x1-1bpp.bmp
content/canvas/test/reftest/webgl-color-alpha-test.html
content/canvas/test/reftest/webgl-color-alpha-test.html

See:
https://tbpl.mozilla.org/php/getParsedLog.php?id=21911132&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=21911249&tree=Mozilla-Inbound
(you can ignore the input file failures in the second log, that is a separate issue)

Comment 1

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

Joe, can you take a look at the bmp image test?

Comment 2

[Joe Drew (not getting mail)]

Argh. Building the emulator from scratch with mozilla-central as gecko, I can't reproduce this. I wonder if it's some bizzare interaction between the B2G emulator and whatever video card it's running on. It's definitely still happening on our R1 machines.

Andrew, one other thought I have is that maybe this has something to do with the specific emulator we're using, but I can't find out where to download those builds (am I just missing something?). Can you point me at them?

(I also can't get reftests to execute properly on my unagi device, which is why I tried on the emulator.)

Comment 3

[Andrew Halberstadt [:ahal]]

(In reply to Joe Drew (:JOEDREW! \o/) from comment #2)
> Andrew, one other thought I have is that maybe this has something to do with
> the specific emulator we're using, but I can't find out where to download
> those builds (am I just missing something?). Can you point me at them?

At the moment, releng doesn't do full stack emulator builds. Meaning they just build gecko and we then install it into an emulator snapshot (containing gaia, gonk, etc.) Bug 807792 tracks getting full builds stood up.

So I think your assessment of the emulator being different is likely accurate. I'll file a bug to get the snapshot updated and we'll see if that resolves the problem or not.

> (I also can't get reftests to execute properly on my unagi device, which is
> why I tried on the emulator.)

Yeah, not sure if anyone's tried to get them running on a unagi or not yet so I'm not surprised.

Comment 4

[Andrew Halberstadt [:ahal]]

Actually Callek pointed out that the emulator snapshot was updated just two days ago. Seeing as we still see the failures, I don't think this is the cause.

I'll pm joe the credentials to the snapshot being used in automation.

Comment 5

[Joe Drew (not getting mail)]

Well, I managed to reproduce the bug on a local build (finally), but I've only been able to verify that the images (1x1 opaque black) are being decoded correctly. Investigation continues...

Comment 6

[Joe Drew (not getting mail)]

We're drawing an opaque black image to the buffer, which ends up writing transparent black to the actual backing buffer because the surface isn't transparent. Then, in GLContext::ReadPixelsIntoImageSurface, we presume the pixels written to the framebuffer are transparent because the destination surface is transparent. This ends up leaving the pixel we're writing to untouched, with whatever value it had originally.

I don't know if it's possible for a GLContext to know whether it's supposed to have alpha; Benoit, do you?

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

There seems to be a GLContext::QueryPixelFormat() that does what you want. If you only need to know about alpha, you may want to code a version of it that only queries that. Really it just binds the GLContext's default framebuffer (which may be a FBO for an offscreen buffer) and calls glGetIntegerv. Jeff Gilbert is likely to be the one who knows this stuff best.

Comment 8

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

(In reply to Benoit Jacob [:bjacob] from comment #7)
> ...
> glGetIntegerv. Jeff Gilbert is likely to be the one who knows this stuff
> best.

Setting needinfo on Jeff.

Comment 9

[Kelsey Gilbert [:jgilbert]]

(In reply to Joe Drew (:JOEDREW! \o/) from comment #6)
> We're drawing an opaque black image to the buffer, which ends up writing
> transparent black to the actual backing buffer because the surface isn't
> transparent. Then, in GLContext::ReadPixelsIntoImageSurface, we presume the
> pixels written to the framebuffer are transparent because the destination
> surface is transparent. This ends up leaving the pixel we're writing to
> untouched, with whatever value it had originally.
> 
> I don't know if it's possible for a GLContext to know whether it's supposed
> to have alpha; Benoit, do you?

This is a boolean stored at `gl->Caps().alpha`.

Comment 10

[Joe Drew (not getting mail)]

Argh. This surface has alpha.

Comment 11

[Joe Drew (not getting mail)]

Attachment: maybe a fix?

This "could" fix the problem. I haven't been able to test it yet because I don't know how to make the emulator know about the new build. So I'm building from scratch and I also pushed this to try.

 https://tbpl.mozilla.org/?tree=Try&rev=5703575aa18d

Comment 12

[Joe Drew (not getting mail)]

This, indeed, does fix the bmp test! I'll split this patch off into a separate bug since it doesn't fix other failures.