Nightly: Bad input lag when running emscripten-generated GL demo (on OSX)

VERIFIED FIXED

Status

()

defect
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: floooh, Unassigned)

Tracking

(Blocks 1 bug, {regression})

23 Branch
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox23 verified)

Details

(Whiteboard: [games:p?][qa-])

Attachments

(1 attachment)

2.47 MB, application/x-gzip
Details
Reporter

Description

6 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130420 Firefox/23.0
Build ID: 20130420031010

Steps to reproduce:

1) In FF Nightly on OSX 10.8.x, go to this URL: http://www.flohofwoe.net/demos/dragons_asmjs.html or http://www.flohofwoe.net/demos/dragons.html 
2) Rotate camera with Left-Mouse-Button + Movement, notice how the demo responds smoothly.
3) Add more dragons with "cursor up" (about 9x), and try to rotate the camera, notice how the camera doesn't properly react, actually all input on the browser tab seems to be affected.

Other browsers, and the public version of FF doesn't have this problem, this is also a relatively new bug in Nighly, a few weeks ago everything worked as expected, but I can't say exactly when the problem started to show up.

I couldn't reproduce the problem on Windows, also another Mac with OSX 10.7.x also has the problem but not as badly.

Also, after fiddling around with other input elements (scrolling the text box etc...) the problem suddenly disappeared, even after reloading the page. But open the demo on a new tab, and the input lag happens again after adding dragons.

Comment 1

6 years ago
Posted file profile

Comment 2

6 years ago
The profile shows buffer swapping as the most expensive thing going on here.
Component: Untriaged → Graphics
Product: Firefox → Core

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression

Comment 3

6 years ago
Andre Weissflog, could you use mozregression to find a regression range, please.
See http://harthur.github.io/mozregression/ for details.
Flags: needinfo?(floooh)
Reporter

Comment 4

6 years ago
Last good build was 2013-04-12, first bad build was 2013-04-13, I'm currently trying to bisect deeper, but building takes a lot of time.
Flags: needinfo?(floooh)
Reporter

Comment 5

6 years ago
Bisecting deeper it says:

The first bad revision is:
changeset:   128501:29a5fd2889f3
user:        Guilherme de Araujo <guimdearaujo@gmail.com>, Brandon Waterloo <brandon.waterloo@gmail.com>
date:        Wed Apr 10 14:38:26 2013 -0400
summary:     Bug 851128 - Introduce custom recognition for the double-tap gesture. r=smichaud
Regression found using mozcommitbuilder 0.4.10 on darwin at 2013-04-21 19:48:33

Not 100% sure though because the debug build is very slow for this demo in any case, and as I wrote above, the bug "disappears" from time to time.

Hope this helps.
Reporter

Comment 6

6 years ago
On the other hand, looking through the bug comments, this *is* an OSX and input-related change, so it might be it.

Updated

6 years ago
Blocks: 851128
Whiteboard: [games:p?]

Comment 7

6 years ago
See also bug 863841, which will essentially revert bug 851128 and implement differently using the Cocoa NSResponder method instead of a custom recognition.

Comment 8

6 years ago
I was able to reproduce the issue on OS X 10.8.2 when using a relatively up-to-date un-patched Nightly on this page:

http://www.flohofwoe.net/demos/dragons.html

(NOTE: on a trackpad only, not on a mouse--on mouse, everything works fine)

Fortunately, the patch from bug 863841 seemed to fix the problem for me.  Could somebody please verify that?  Also, if you're using Lion (10.7.*), we aren't sure that the method in the patch works for Lion, so if you could test that as well, that'd be sweet!


HOWEVER, this page causes a "Segmentation fault: 11" every time either with or without the patch, which is a whole new can of worms:

http://www.flohofwoe.net/demos/dragons_asmjs.html

Here's what GDB found for me:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
js::Vector<js::ion::MBasicBlock*, 1ul, js::ion::IonAllocPolicy>::append<js::ion::MBasicBlock*> () at /Users/firefox/Firefox/mozilla-central/obj-x86_64-apple-darwin12.2.0/dist/include/js/Vector.h:846
846	    REENTRANCY_GUARD_ET_AL;

Whatever the segfault is, it is well beyond my area of expertise. I'm going to try a more recent Nightly build in a few minutes, if the issue still exists, I'll file a bug.
Reporter

Comment 9

6 years ago
The asm.js version doesn't run for me as well, but only with the Debug-Nightly-Builds. I'll notify the guys on the emscripten of this. Thanks for looking into this.

Updated

6 years ago
See Also: → 863841
> 3) Add more dragons with "cursor up" (about 9x)

What does this mean?

Comment 11

6 years ago
(In reply to Steven Michaud from comment #10)
> > 3) Add more dragons with "cursor up" (about 9x)
> 
> What does this mean?

Press the Up arrow key 9 times until there's several hundred dragons. Then, camera panning with trackpad is super laggy/jerky.
Thanks, Brandon, for the info.

I can reproduce this bug on both OS X 10.8.3 and 10.7.5.  In my (very brief) testing it actually seems to be worse on 10.7.5 (though this may just be an accident).

Brandon, I think you should back out your patch for bug 851128.  Your patch for bug 863841 has problems of its own, and we probably won't be able to land it for a while.

Or I can back out your patch for bug 851128 myself, since I have commit privileges.

Comment 13

6 years ago
Since I don't have commit privileges, you should back it out. Thanks!

Updated

6 years ago
See Also: → 862417

Comment 14

6 years ago
Now that the bad patch for bug 851128 is backed out, I tried this again and the problem seems to be fixed. Can anyone confirm, and if so, can we mark this bug as fixed?
The backout of bug 851128 landed on mozilla-central too late to get into today's mozilla-central nightly.  It'll be in tomorrow's, though.
Reporter

Comment 16

6 years ago
Cannot reproduce the problem in Nightly 2013-04-24, looks good. 

Only thing I noticed... were those Nightly updates always only 5MB, I seem to remember they've been much bigger...?
Marking this fixed on the strength of comment #16.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 18

6 years ago
(In reply to comment #16)
> Only thing I noticed... were those Nightly updates always only 5MB, I seem to
> remember they've been much bigger...?

Typically if you update to the next Nightly, you'll get a "partial mar" which is basically a binary diff between the two builds, which is a lot smaller.  If you download a nightly further into the future, you'll get a "complete mar" since we don't generate those diffs between all builds.  "mar" is the archive format that we use to package our updates into.
I can't reproduce this issue with the Nightly from 2013-04-13, on a Mac OSX 10.8.3 machine in 32bit mode, using the STR from the description.

Does anyone have any thoughts/suggestions?
Flags: needinfo?
Flags: needinfo?
QA Contact: manuela.muntean
Flags: needinfo?
Marking [qa-] since QA cannot reproduce the original issue as described, thus won't be able to reliably verify this is fixed. Andre, if you can no longer reproduce this in the latest Beta, please set this bug to VERIFIED FIXED.

Thanks
Flags: needinfo?
Keywords: verifyme
Whiteboard: [games:p?] → [games:p?][qa-]
Reporter

Comment 21

6 years ago
Confirmed fixed in current Firefox 23 Beta. As I remember it was a trackpad-only thing and not related to emscripten or WebGL at all, but instead some multi-touch gesture code on OSX.
Status: RESOLVED → VERIFIED

Comment 23

6 years ago
Andre is correct; it was related to some work on recognizing multi-touch gestures.  All of the gesture recognition that was causing problems has been replaced; through some trial and error and a lot of research we found the correct way to recognize multi-touch gestures (in particular, double tap) on OS X.

This bug was originally caused by one of my changes, and subsequently fixed by one.
You need to log in before you can comment on or make changes to this bug.