Closed Bug 915010 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: Graphics, defect, critical)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 934886
1.2 C3(Oct25)
blocking-b2g koi+
Tracking Status
b2g-v1.2 --- affected

People

(Reporter: nhirata, Assigned: gw280)

References

Details

Attachments

(3 files, 1 obsolete file)

Attached image 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
blocking-b2g: --- → koi?
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.
Summary: [leo][1.2] launching an app and then going to the task manager will show graphic defect for the screenshots → [leo][1.2] screenshot api will show graphic defect for the screenshots
Duplicate of this bug: 915966
Duplicate of this bug: 917017
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.
Triage team, please koi+ this bug.  Leo will likely be a market device supporting FOTA to 1.2
QA Contact: nkot
I'm pretty sure it's a driver issue; This only happens on leo.
to note, the leo team should be aware of this bug.
Component: General → Vendcom
Whiteboard: [POVB]
QA Contact: nkot
blocking-b2g: koi? → ---
Duplicate of this bug: 922816
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.
blocking-b2g: --- → koi?
Attached video 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.
Severity: normal → critical
blocking-b2g: koi? → koi+
Component: Vendcom → General
Whiteboard: [POVB]
Component: General → Graphics
Product: Boot2Gecko → Core
It is fine on Unagi.  Sotaro, is it pmem related?
Flags: needinfo?(sotaro.ikeda.g)
Version: unspecified → Trunk
(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.
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)
(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.
Duplicate of this bug: 925454
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
Blocks: GFXB2G1.2
milan, can you re-assign a person who knows SkiaGL?
Assignee: sotaro.ikeda.g → milan
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.
Assignee: milan → gwright
Duplicate of this bug: 927111
Target Milestone: --- → 1.2 C3(Oct25)
This is a high priority bug blocking partner certification, do we have any idea of the scope here?
I have high confidence that this is the same bug as 915783, which has a fix.
The patch in bug 915783 does not fix the task switcher for me.
This kind of looks like an RGB565/RGBA8888 mismatch?
Summary: [leo][1.2] screenshot api will show graphic defect for the screenshots → [leo][1.2] screenshot api will show graphic defect for the screenshots (e.g. app switcher, browser tab thumbnails and on homepage)
This bug seems to be stagnating. Given this is a v1.2 blocker is disabling SkiaGL in v1.2 an option?
Flags: needinfo?(gwright)
(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.
Flags: needinfo?(gwright)
Milan why is there no progress here?
Flags: needinfo?(milan)
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.
Flags: needinfo?(milan)
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?
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.
(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.
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.
Attached file egl.trace
apitrace file of gaia loading up, opening the browser app, then bringing up the app switcher
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 :(
Flags: needinfo?(cku)
CJ, can you get somebody in Taipei to take a look at this until George is back in Toronto on Monday?
Sure
Peter/ Solomon, please check this issue
Flags: needinfo?(schiu)
Flags: needinfo?(pchang)
Flags: needinfo?(cku)
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
Flags: needinfo?(pchang)
Attached patch patch for b2g 1.2 (obsolete) — Splinter Review
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 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.
Attachment #825912 - Attachment is obsolete: true
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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.
Depends on: 934886
I just updated the root cause on bug 934886.
Most of the conversation is in the bug 934886 that Peter mentioned.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 934886
Flags: needinfo?(schiu)
You need to log in before you can comment on or make changes to this bug.