915010 - [leo][1.2] screenshot api will show graphic defect for the screenshots (e.g. app switcher, browser tab thumbnails and on homepage)

Status: RESOLVED DUPLICATE of bug 934886

(Core :: Graphics, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: 2013-09-11-09-49-43.png

Gaia   6deda9d7c51f278443f704217eaed722044a03e7
Gecko be1053dc223b
BuildID 20130910040201
Version 26.0a1
Base Build 10A
Device: Leo

1. launch application
2. hold down the home button to get to the task manager

Expected: screenshots of application should look like the application in it's last state
Actual: green/pink lines through the application

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Turns out that the browser app will also show this issue for the top sites and tabs.  Spoke with Ben Francis and found that the browser uses the screenshot api.

Comment 4

[Jason Smith [:jsmith]]

Don't think a regression window will be possible, but let's double check to be sure with the oldest build available for 1.2.

Comment 5

[Tony Chung [:tchung]]

Triage team, please koi+ this bug.  Leo will likely be a market device supporting FOTA to 1.2

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I'm pretty sure it's a driver issue; This only happens on leo.

Comment 7

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

to note, the leo team should be aware of this bug.

Comment 9

[Ben Francis [:benfrancis]]

This is also reproduceable on Geeksphone's nightly 1.2 builds for the Keon (and possibly Peak). You will also see it if you flash a hamachi/buri with our own gonk builds (not recommended).

I suspect this is a bad kernel driver or gonk/gecko mis-match but we should figure out how we're ending up with broken builds and make the necessary configuration changes.

Renominating because we shouldn't ship 1.2 until this is resolved.

Comment 10

[Diego Wilson [:diego]]

Attachment: VID_0007.3gp

I can reproduce this on a reference device with v1.2. Mind you, this is with a full build from source (including kernel, gecko and gaia). I'm afraid this isn't just a mismatch issue. Video attached.

Comment 11

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

It is fine on Unagi.  Sotaro, is it pmem related?

Comment 12

[Jason Smith [:jsmith]]

(In reply to Milan Sreckovic [:milan] from comment #11)
> It is fine on Unagi.  Sotaro, is it pmem related?

Fine on Buri as well. Leo is one device we've seen the problem on, although the dupes imply that one of QC's devices they are using to test is affected as well.

Comment 13

[Sotaro Ikeda [:sotaro]]

(In reply to Milan Sreckovic [:milan] from comment #11)
> It is fine on Unagi.  Sotaro, is it pmem related?

I confirmed that the problem happened on v1.2 leo. I feel it is not related to pmem. I am going to investigate about it.

Comment 15

[Sotaro Ikeda [:sotaro]]

On leo device, When disabling SkiaGL, the problem is gone. It seems like SkiaGL related problem.
To disable SkiaGL, comment out the following preferences.
  http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#821

Comment 16

[Sotaro Ikeda [:sotaro]]

milan, can you re-assign a person who knows SkiaGL?

Comment 17

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

This is not necessarily a bug *in* SkiaGL, but it is exposed when we switch to using SkiaGL/accelerated canvas.  Bug 915783 is another one related to SkiaGL/accelerated canvas.

Comment 19

[Lucas Adamski [:ladamski]]

This is a high priority bug blocking partner certification, do we have any idea of the scope here?

Comment 20

[James Willcox (:snorp) ([e-mail]) (he/him)]

I have high confidence that this is the same bug as 915783, which has a fix.

Comment 21

[Diego Wilson [:diego]]

The patch in bug 915783 does not fix the task switcher for me.

Comment 22

[George Wright (:gw280) (needinfo me!)]

This kind of looks like an RGB565/RGBA8888 mismatch?

Comment 25

[Diego Wilson [:diego]]

This bug seems to be stagnating. Given this is a v1.2 blocker is disabling SkiaGL in v1.2 an option?

Comment 26

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

(In reply to Diego Wilson [:diego] from comment #25)
> This bug seems to be stagnating. Given this is a v1.2 blocker is disabling
> SkiaGL in v1.2 an option?

May look like it, but we're actively working on it.

Comment 27

[Andreas Gal :gal]

Milan why is there no progress here?

Comment 28

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

We are looking for a solution that doesn't just disable SkiaGL. We also really just started on it this week, as we were working on bug 915783.

Comment 29

[George Wright (:gw280) (needinfo me!)]

I'm trying to get Leo to work, but:

- master branch appears to be completely broken. I built it, and flashed gaia/gecko (I've been informed that I can't do a full build, so I can only build those two and flash them), and it froze on the fox animation boot screen.
- v1.2 branch built and worked, and I get to the language selection screen, but if I hit "next" the whole system freezes and I can't do anything else.

Is anyone able to suggest how I can get this leo device to work?

Comment 30

[George Wright (:gw280) (needinfo me!)]

Observing it more closely, it appears that the first touch event on the screen is recorded, and it behaves as if we get the touch down event, but it never releases and a touch up is never recorded.

Comment 31

[[:fabrice] Fabrice Desré]

(In reply to George Wright (:gw280) from comment #30)
> Observing it more closely, it appears that the first touch event on the
> screen is recorded, and it behaves as if we get the touch down event, but it
> never releases and a touch up is never recorded.

You need a new boot image. ping me to get it.

Comment 32

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

George, keep us up to date when the day ends - unless you fix it in a day, I'd like to continue this in Taipei so that we don't lose momentum while you're traveling back to Toronto.

Comment 33

[George Wright (:gw280) (needinfo me!)]

Attachment: egl.trace

apitrace file of gaia loading up, opening the browser app, then bringing up the app switcher

Comment 34

[George Wright (:gw280) (needinfo me!)]

Some quick comments:

- The framebuffer in the apitrace trace seems to be completely hosed. Not sure what exactly is going on there.
- The texture that is created to hold the screenshot is 512x512, which is a next power-of-two expansion of the contents of it. Its type is GL_BGRA, and I suspect we're trying to read it as GL_RGB with UNSIGNED_BYTE_565 somewhere.

I've got to head out for now, so as per Milan's request I'm needinfoing CJ Ku. I will continue investigating but I may or may not have access to a Leo device until I get back to Toronto :(

Comment 35

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

CJ, can you get somebody in Taipei to take a look at this until George is back in Toronto on Monday?

Comment 36

[u459114]

Sure
Peter/ Solomon, please check this issue

Comment 37

[Peter Chang[:pchang]]

This issue could be reproduced if only set skia as canvas backend. Therefore, it isn't the skiaGL issue.

The following line will generates the canvas blob() by cairo.
Change to sourcesurface API could fix the problem for skia case.
(correct color/size but with skew snapshot, same code on master didn't have the skew problem) 

But it only see the black snapshot for skiaGL case.

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/file/163f34a949e9/content/canvas/src/CanvasRenderingContext2D.cpp#l1087

Comment 38

[Peter Chang[:pchang]]

Attachment: patch for b2g 1.2

Attched my debug patch. You can witch skia/skiaGL by 
"adb shell setprop debug.gfx.skiaGL 1" or 
"adb shell setprop debug.gfx.skiaGL 0".

Comment 39

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 825912 [details] [diff] [review]
patch for b2g 1.2

Review of attachment 825912 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/canvas/src/CanvasRenderingContext2D.cpp
@@ +1117,5 @@
> +  if (!sourceSurface) {
> +    return NS_ERROR_FAILURE;
> +  }
> +
> +  mTarget->CopySurface(sourceSurface,

Did you try this? How could it work? CopySurface() copies the passed-in surface into the DT, not vice-versa.

Comment 40

[Peter Chang[:pchang]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #39)
> Comment on attachment 825912 [details] [diff] [review]
> patch for b2g 1.2
> 
> Review of attachment 825912 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: content/canvas/src/CanvasRenderingContext2D.cpp
> @@ +1117,5 @@
> > +  if (!sourceSurface) {
> > +    return NS_ERROR_FAILURE;
> > +  }
> > +
> > +  mTarget->CopySurface(sourceSurface,
> 
> Did you try this? How could it work? CopySurface() copies the passed-in
> surface into the DT, not vice-versa.

You are right. I guess I saw the cached memory output for screenshot.

But I did see the same graphic defect when switch between skia and skiaGL.

Comment 41

[Peter Chang[:pchang]]

I just updated the root cause on bug 934886.

Comment 42

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

Most of the conversation is in the bug 934886 that Peter mentioned.