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

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.

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

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.

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.

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.

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

(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.

(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.

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

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

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.

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?

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

(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.

Milan why is there no progress here?

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.

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.

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 :(

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

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

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.

(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.

I just updated the root cause on bug 934886.

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