1247142 - GDC 2016 Demo of Debugging Tools using SpryFox's Alphabear

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Description

[Anthony Vaughn [:anthony][:avaughn][San Francisco - Pacific]]

This is to capture the deliverable of the debugger demo using SpryFox's "Alphabear" game. SpryFox has agreed, in email, to let use the game. We're just waiting on the legal agreement to go through. That can be done in parallel to the demo being created so we don't lose time for GDC.

Comment 1

[Anthony Vaughn [:anthony][:avaughn][San Francisco - Pacific]]

Checking in on this. I know Jordan is out of town for the next few work days so I'd like to understand who is the point person on this for now. What we need to nail down by Tuesday of next week (02/16) is whether or not we are going to use Alphabear for this (I recommend we do since Jukka already has source). Also, any way to incorporate WASM into this would be great too.

Who can take this on tomorrow and next week?

Thanks much!

Comment 2

[Luke Wagner [:luke]]

If we want to demo devtools with Alphabear, I think we'd have to keep it confined to profiler and any canvas (webgl) tools.  The debugger falls over dead in multiple ways: (1) asm.js optimizations are disabled so it runs poorly (like it did on release before bug 1240583), (2) unless it's been fixed recently, the debugger UI hangs for the super-large asm.js files.

Comment 3

[Jordan Santell [:jsantell] [@jsantell]]

Adding memory tools' tree map, and the initial wasm debugging capabilities as blockers. No one's assigned to the wasm debugging support (showing source in the debugger), so these are just some goals that may or may not be done in time.

The wasm debugging we talked about in Orlando for the first step was to list the wasm sources in the debugger (bug 1232014), and display a message saying wasm debugging is not supported yet -- and if we can get a text representation of wasm (bug 1232011) to display in the debugger (bug 1232012), this would be a great thing to display in the mean time, even though we can't debug it yet, I believe. Not sure the work involved here, but I think it might be doable in time based on others' confidence of the relatively straight-forward difficulty. Thoughts?

@Luke: there's been a few enhancements to the debugger to handle large files -- this should work for large asm files now, but haven't confirmed yet. Also I believe we only disable optimizations if setting breakpoints, so that may be better now, but I'm not up to date on the details. CC'd James and Eddy

Comment 4

[Luke Wagner [:luke]]

(In reply to Jordan Santell [:jsantell] [@jsantell] (Please needinfo) from comment #3)
> No one's assigned to the wasm debugging support (showing source
> in the debugger), so these are just some goals that may or may not be done
> in time.

Definitely debugging will not be done for GDC (or even fully started); that's a summer goal on which shu was offering to help.

> The wasm debugging we talked about in Orlando for the first step was to list
> the wasm sources in the debugger (bug 1232014), and display a message saying
> wasm debugging is not supported yet -- and if we can get a text
> representation of wasm (bug 1232011) to display in the debugger (bug
> 1232012), this would be a great thing to display in the mean time, even
> though we can't debug it yet, I believe. Not sure the work involved here,
> but I think it might be doable in time based on others' confidence of the
> relatively straight-forward difficulty. Thoughts?

Given that wasm will be, effectively, eval'd around the GDC time frame, normal "View Source" won't be meaningful (there won't be script URLs to click on in Debugging) until we have more Debugger integration.  (After ES6 modules ship, we can integrate wasm modules so that wasm will directly loadable via URL so then it would show up like a normal script.)

> Also I believe we only disable optimizations if setting breakpoints, so that may
> be better now, but I'm not up to date on the details. CC'd James and Eddy

That's true for normal JS, but not asm.js.  There's a special debuggerObservesAsmJS flag that gets set to 'true' when you click the Debugger tab that causes asm.js to be treated like normal JS.

Comment 5

[James Long (:jlongster)]

Can this bug be closed? GDC has come and gone

Comment 6

[Jordan Santell [:jsantell] [@jsantell]]

Yup, closing