Closed Bug 1014011 Opened 10 years ago Closed 10 years ago

[Meta] Emscripten/WebGL game running too slow in 1.4

Categories

(Core :: Graphics: CanvasWebGL, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
2.0 S5 (4july)
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- fixed
b2g-v2.0 --- unaffected
b2g-v2.1 --- unaffected

People

(Reporter: mbest, Assigned: jrmuizel)

References

Details

(Keywords: meta, perf, Whiteboard: [c=progress p= s=2014.07.04.t u=1.4])

We are looking to include the first Emscripten/WebGL game with 1.4.  We are running into what appear to be WebGL bottle neck that is hampering efforts to get us to where we need to be.  This bug is a meta bug to track our progress towards reaching minimum viability which is determined by the products license holder finding the experience provided worthy and sign off on shipping the product on the device.
The current game is running at about 25fps on the higher order levels.  To get approval we need to get to about 30fps and have that be relatively stable.  No more than a 5 fps fluctuation during primary level game-play.
blocking-b2g: --- → 1.4?
Keywords: perf
I'm not convinced this blocks bug 1006164, but let's see.
Blocking for additional perf improvement.
blocking-b2g: 1.4? → 1.4+
Summary: Emscripte/WebGL game running too slow in 1.4 → Emscripten/WebGL game running too slow in 1.4
Blocks: 999694
No longer blocks: 999694
I'm unblocking this since this is a meta bug.
blocking-b2g: 1.4+ → ---
(In reply to Jason Smith [:jsmith] from comment #4)
> I'm unblocking this since this is a meta bug.

Please nominate the critical dependencies that are needed for 1.4.
Keywords: meta
In most cases, it's not possible to tell how much fixing a performance bug will improve performance until the performance bug has actually been fixed and a new profile is measured. In that sense, I'd say all the dependencies are critical, until we have met the required performance, which is reaching stable 30fps throughout the game.

To my knowledge, Benoit Girard, Jeff Gilbert, Jeff Muizelaar and Sotaro Ikeda are currently the people closest to working on the dependencies listed here. I'm hoping that they will be able to chime in and give an estimate of how tough the individual issues look like, and which ones we will ultimately need to push in to reach the bar.
Jason, this is a similar issue we had with the checkerboarding.  We tracked and used the meta bug as the blocker and the dependency because we didn't know which one is going to work for us.  For this scenario, even though it is a meta, it should be left as a blocker.

Jukka, I'm not sure it's productive listing all of the bugs are being blockers for this.  As we know, and you actually stated, we don't know which ones we'll need, so listing them as "all of these need to be fixed for this bug to be resolved" is not what you're actually trying to say.

The bugs that end up being actionable and need to be fixed can then be nominated and uplifted and made as a blocker of this one.  But for now, I would remove the dependent bugs (Jukka, you can just list them in see also or in one of the comments) and I would put this back to 1.4+.
blocking-b2g: --- → 1.4?
Flags: needinfo?(jujjyl)
Flags: needinfo?(jsmith)
Okay fair enough.
blocking-b2g: 1.4? → 1.4+
Flags: needinfo?(jsmith)
Yes indeed, I'm not stating that all of them need to be fixed, just enough of them that we'll meet performance. I thought that adding dependencies is the preferred way to refer to other bugs, but sure, a comment will do fine as well. Let me remove the dependencies and just list them as a comment here:

Bug #767484 - Implement ANativeWindow backed EGLSurface
Bug #988573 - WebGL buffer present machinery calls into glReadPixels.
Bug #999694 - Use fence objects in SharedSurfaceGralloc
Bug #999713 - Call MakeCurrent universally, but lazily
Bug #1011017 - Certain WebGL operations take disproportionally long time compared to other platforms.
Bug #1013647 - WebGL operation still calls to eglGetError() after almost each operation.
Bug #1014203 - Simple page with a canvas doesn't get a color layer for the background
Bug #1014209 - Performance impact from enabling WEBGL_draw_buffers
Bug #1008216 - WebGL rendering is not performed fully parallel to JavaScript execution.

Bug #998916 - Defer the webgl context restore until the app becomes foreground
Bug #1009553 - Canvas webglcontextrestored event is raised when application is in background mode.
Flags: needinfo?(jujjyl)
Depends on: 1001417
We have a solution, the majority of the work remaining is to produce a 1.4 version and not have to uplift a lot.
Priority: -- → P1
Whiteboard: [c=progress p= s= u=1.4]
Summary: Emscripten/WebGL game running too slow in 1.4 → [Meta] Emscripten/WebGL game running too slow in 1.4
Making Jeff the meta bug owner, he's coordinating which fixes end up in 1.4.
Assignee: nobody → jmuizelaar
Depends on: 1014815
Depends on: 1024025
Depends on: 1024144
No longer depends on: 1014815
Triage team: since we have partner sign-off, games team is good with holding on further uplifts unless there is a regression which causes us to go below performance observed as of 06/11 gecko-gaia build.Thank you very much for your support to get 1.4 to the level we need for games.
No longer depends on: 1024025
Depends on: 1024025
No longer depends on: 1024025
To be clear, we are still investigating bug 1022823 so if this is 100% reproducible some of the proposed fixes may bounce back.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S5 (4july)
Whiteboard: [c=progress p= s= u=1.4] → [c=progress p= s=2014.07.04.t u=1.4]
You need to log in before you can comment on or make changes to this bug.