Closed Bug 1011865 Opened 10 years ago Closed 10 years ago

[B2G][Marketplace][Poppit] The 'Poppit' app is too slow

Categories

(Core :: Graphics, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
mozilla32
blocking-b2g 2.0+
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.
blocking-b2g: --- → 2.0?
Switching to qawanted to get a video & a logcat.
I wonder if this is similar to 999841.
QA Contact: lmauritson
Keywords: qawanted
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.
Priority: -- → P1
Whiteboard: [c=progress p= s= u=2.0]
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 <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
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)
Blocks: 950372
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.
Flags: needinfo?(pchang)
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+
https://hg.mozilla.org/mozilla-central/rev/bb71ae94a9fd
Status: NEW → RESOLVED
Closed: 10 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.

Attachment

General

Created:
Updated:
Size: