Closed Bug 862787 Opened 9 years ago Closed 5 years ago

Four reftest failures on b2g emulator after layers refactoring

Categories

(Core :: Graphics: Layers, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: ahal, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(1 obsolete file)

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)
Joe, can you take a look at the bmp image test?
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.)
Flags: needinfo?(ahalberstadt)
(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.
Flags: needinfo?(ahalberstadt)
Depends on: 866082
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.
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...
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?
Flags: needinfo?(bjacob)
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.
Flags: needinfo?(bjacob)
(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.
Flags: needinfo?(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`.
Flags: needinfo?(jgilbert)
Argh. This surface has alpha.
Attached patch maybe a fix? (obsolete) — Splinter Review
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
Assignee: nobody → joe
Attachment #745401 - Flags: review?(bjacob)
This, indeed, does fix the bmp test! I'll split this patch off into a separate bug since it doesn't fix other failures.
Assignee: joe → nobody
Attachment #745401 - Attachment is obsolete: true
Attachment #745401 - Flags: review?(bjacob)
No longer blocks: 869011
Depends on: 869011
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.