Closed Bug 1011865 Opened 7 years ago Closed 7 years ago
[B2G][Marketplace][Poppit] The 'Poppit' app is too slow
+++ This bug was initially created as a clone of Bug #1009980 +++ This bug is created based on Bug 1009980 Comment 8. *STR  Download the app 'Poppit' from the marketplace.  Launch 'Poppit'.  Start to play game *Actual result The poppit app is too slow to play. This problem happen only on master. I confirmed this by using master hamachi, master flame. The problem did not happen v1.4 flame.
I wonder if this is similar to 999841.
Blocking as observed in the video that the lag was very obvious and this is a regression in 2.0 Hoping the regression-window will help us find the root cause.
blocking-b2g: 2.0? → 2.0+
Attachment #8426042 - Attachment mime type: text/plain → text/html
The following are two profilers of guimark2 on b2g master and 1.4 local build. b2g master spends more time on SurfaceStream_TripleBuffer::SwapProducer which invokes SharedSurfaceGralloc::Fence to read pixels. profiler on b2g master http://people.mozilla.org/~bgirard/cleopatra/#report=e05813461f2a43d6a67405543754f9065227327d profiler on b2g 1.4 http://people.mozilla.org/~bgirard/cleopatra/index.html?#report=676ff0707442bf07644d7a3ffe16457b2f295877
For what its worth, I saw a lot of SurfaceStream_TripleBuffer::SwapProducer recently in a game on win8 over in bug 1013039.
Triage: From comment 4, this looks like a regression. Waiting on a regression window before acting.
Regression window in Mozilla inbound Last Working Build: 20140415105558 Gaia: 3d47c0627017ef77b1adf179792c6543a349af72 Gecko: e134b3aa718f Version: 31.0a1 First Broken Build: 20140415110403 Gaia: 3d47c0627017ef77b1adf179792c6543a349af72 Gecko: a54345bfd338 Version: 31.0a1 New Gaia old Gecko: Working Gaia: 3d47c0627017ef77b1adf179792c6543a349af72 Gecko: e134b3aa718f Old Gaia new Gecko: Broken Gaia: 3d47c0627017ef77b1adf179792c6543a349af72 Gecko: a54345bfd338 Determined to be a Gecko issue. Push log: hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e134b3aa718f&tochange=a54345bfd338
I just confirmed this issue was caused by below commit. changeset: 178703:a54345bfd338 user: Jonathan Watt <email@example.com> date: Tue Apr 15 19:02:23 2014 +0100 files: browser/components/shell/src/nsWindowsShellService.cpp content/svg/content/src/SVGFEImageElement.cpp gfx/2d/DataSurfaceHelpers.h image/public/imgIContainer.idl image/src/ClippedImage.cpp image description: Bug 950372 - Convert imgIContainer::GetFrame to return a Moz2D SourceSurface instead of a Thebes gfxASurface. r=mattwoodrow
Jonathan, I'd rather not just back this out if you have a chance to take a look and get us a "real" fix.
Assignee: nobody → jwatt
Peter, did bug 996929 not then fix this (in which case there must have been a later regression that regressed things again).
Flags: needinfo?(jwatt) → needinfo?(pchang)
It did not.
Taking this at the request of jwatt.
Assignee: jwatt → matt.woodrow
I looks like bug 996929 did the right thing to fix this, but the skia(-gl) backend code still wasn't doing the right thing.
Attachment #8427496 - Flags: review?(gwright) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Whiteboard: [c=progress p= s= u=2.0] → [c=progress p= s=2014.05.23.t u=2.0]
Does this actually cause images to be cached in GPU? I had a similar patch, but I had to mark the surface as non-volatile for skia to do the right thing. Without that, I couldn't see any difference in the fishietank benchmark. static_cast<SourceSurfaceSkia*>(result.get())->mBitmap.setIsVolatile(false);
You need to log in before you can comment on or make changes to this bug.