Closed
Bug 1011865
Opened 11 years ago
Closed 11 years ago
[B2G][Marketplace][Poppit] The 'Poppit' app is too slow
Categories
(Core :: Graphics, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
b2g-v2.0 | --- | fixed |
People
(Reporter: sotaro, Assigned: mattwoodrow)
References
Details
(Keywords: perf, regression, Whiteboard: [c=progress p= s=2014.05.23.t u=2.0])
Attachments
(3 files)
+++ This bug was initially created as a clone of Bug #1009980 +++
This bug is created based on Bug 1009980 Comment 8.
*STR
[1] Download the app 'Poppit' from the marketplace.
[2] Launch 'Poppit'.
[3] 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.
Reporter | ||
Updated•11 years ago
|
blocking-b2g: --- → 2.0?
Reporter | ||
Updated•11 years ago
|
Keywords: regressionwindow-wanted
Comment 2•11 years ago
|
||
I wonder if this is similar to 999841.
Updated•11 years ago
|
QA Contact: lmauritson
Comment 3•11 years ago
|
||
Video: http://youtu.be/8c4FY1b6uS4
Updated•11 years ago
|
Keywords: regressionwindow-wanted
Comment 4•11 years ago
|
||
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+
Comment 6•11 years ago
|
||
Updated•11 years ago
|
Attachment #8426042 -
Attachment mime type: text/plain → text/html
Comment 7•11 years ago
|
||
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
Comment 8•11 years ago
|
||
For what its worth, I saw a lot of SurfaceStream_TripleBuffer::SwapProducer recently in a game on win8 over in bug 1013039.
Updated•11 years ago
|
Priority: -- → P1
Whiteboard: [c=progress p= s= u=2.0]
Comment 9•11 years ago
|
||
Triage: From comment 4, this looks like a regression. Waiting on a regression window before acting.
Comment 10•11 years ago
|
||
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
Keywords: regressionwindow-wanted
Comment 11•11 years ago
|
||
I just confirmed this issue was caused by below commit.
changeset: 178703:a54345bfd338
user: Jonathan Watt <jwatt@jwatt.org>
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
Comment 12•11 years ago
|
||
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
Flags: needinfo?(jwatt)
![]() |
||
Comment 13•11 years ago
|
||
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)
Assignee | ||
Comment 15•11 years ago
|
||
Taking this at the request of jwatt.
Assignee: jwatt → matt.woodrow
Assignee | ||
Comment 16•11 years ago
|
||
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.
Assignee | ||
Comment 17•11 years ago
|
||
Attachment #8427496 -
Flags: review?(gwright)
Updated•11 years ago
|
Attachment #8427496 -
Flags: review?(gwright) → review+
Assignee | ||
Comment 18•11 years ago
|
||
Comment 19•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Updated•11 years ago
|
status-b2g-v2.0:
--- → fixed
Updated•11 years ago
|
Whiteboard: [c=progress p= s= u=2.0] → [c=progress p= s=2014.05.23.t u=2.0]
Comment 20•11 years ago
|
||
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.
Description
•