mstange

Are there any tools that help finding these kinds of things? Like a profiler that says "80% of the allocated bytes are objects of this type, with 95% of those having that field set to None"

You can expect some blog posts from us on this topic at the end of the year / early next year. In short: Organizational focus on a performance target, significant investment, and some great new tooling. We're also reaping the benefits of foundational work that happened over the last few years.

This appears to be a box-shadow which bleeds out of the input type="range". It seems that there's a missing overflow:hidden somewhere.

I've found two examples of DWARF expressions in the wild: 1. A handwritten expression in libpthread <= 2.19, which was removed in 2014 [1], and 2. the expression covering the PLT section of most binaries. [2]

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1157194#c14

[2] https://github.com/mstange/framehop/blob/6777199dd0c2c1b3768...

It works with optimized builds, and it works better with them than gdb does.

When you debug an optimized build with debug info in gdb by stepping line by line, it is easy to accidentally step "too far" and completely lose your place. In rr, you can always step back and recover.

Oh, you're right. I missed that.

For people who are experiencing a leak on macOS 12: Check if you have set a custom cursor color in the system accessibility preferences. Resetting the cursor color to the default may fix it.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1735345#c18

(edit: rephrased to mention macOS 12)

WASD doesn't work by default because I'm using a Dvorak keyboard layout. Using KeyEvent.code would solve this problem.

My experience was similar: File.pizza didn't work. However, https://justbeamit.com/ worked flawlessly.

APIs for partial compositing in combination with hardware accelerated compositing was the thing that was missing. If you don't use hardware accelerated compositing, repainting only part of the window, and letting the system compositor know about those areas, is not a problem. It's only the GPU acceleration and the lack of convenient APIs that makes this a problem.

Before Firefox got hardware acceleration, so up until Firefox 3.6, we were using CPU-side painting and sending accurate dirty areas to the windowing system. With Firefox 4, we added hardware accelerated compositing, which made scrolling and transform / opacity animations a lot more performant. However, it also meant that we switched to using OpenGL for the compositor, and macOS does not expose any APIs for invalidating only parts of an OpenGL context. And at the time Firefox 4 shipped, "retina" displays were not a thing yet, so the impact of recompositing the entire window was not apparent. And there was the pervasive notion that "modern GPUs are fast, fill rate is not a problem". It was only as pixel count grew and grew that this started becoming problematic. And it took some amount of research and a lot of surgery to switch Firefox to an approach that gets OpenGL content to the screen while also allowing for partial updates of that OpenGL content.

I couldn't find an API for it, but some Apple apps do in fact do this. I've seen three examples of it:

- Media playback: When a song or a video is playing in a background app, there is an extra button in the system button part on the right that lets you access a media control strip. From it you can pause the current video / audio and even scrub through it.

- Xcode debugging: While Xcode is attached to a running process, there's a button in the system button part on the right side of the touch bar lets you access a debugging control strip, which lets you pause execution and step through the program. This access button is actually in the same place as the media control button, and in cases where both would be shown, the media control button wins.

- QuickTime screen recording: When you start recording the screen from QuickTime, the current recording time + a stop button is displayed in a touch bar overlay even if you focus a different app. However, once you do switch to a different app, you can close the overlay, and it minimizes into that same button slot on the right of the touch bar.

It surely would be nice to be able to do these things without private APIs, but I couldn't find anything so far.

It's 5-10 fps in Firefox Nightly for me, and 50-60 fps in Chrome Canary, on OS X.

Scrolling especially should be much better in multi-process Firefox, because it will be async, so web pages no longer block it.

It doesn't fix performance in your react app, though. I've filed a bug about it: https://bugzilla.mozilla.org/show_bug.cgi?id=1300848

Thanks!

Oh no, it's that box-shadow bug again :-(

We fixed in in Firefox 47, but the fix was deemed too risky to be uplifted to Firefox 46. That was probably a mistake. Anyway, Firefox 47 is going to be released in two weeks on June 7th. In the meantime you can remove the box-shadow from .widewrapper.main using the devtools, or you can use Firefox Beta (47) or Firefox Developer Edition (48), which you can get here: https://www.mozilla.org/en-US/firefox/channel/#developer

Thanks for finding that out. We (Firefox) fixed a box shadow performance bug [1] in Firefox 47, which will be released on June 7th. It looks like this site is hitting that perf bug.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1250947

In the future it'll be possible to use keyEvent.code for this: http://www.w3.org/TR/DOM-Level-3-Events/#keys-codevalues

It's supported in Firefox Nightly + Dev edition. I don't know whether other browsers support it yet.

Nightly and Aurora Firefox builds actually support the "code" field on keyboard events, which lets JS know which physical key was pressed on the keyboard. For example, when a Dvorak user presses the key that would be W on a QWERTY layout (for moving forwards in a game), you'll get a keydown event with e.key == "," and e.code == "KeyW".

I'd really like to know what the spec status on that is, and whether other browsers implement it.

Using the new Firefox profiler [0], which isn't quite ready for public consumption yet but already very helpful:

1. Download Firefox Nightly [1]

2. Install the profiler addon [2]

3. Play the game

4. Press Cmd+Shift+O to open a profile of the most recent few seconds

5. Wade through the tree until you find nsIDOMHTMLImageElement_SetSrc, which is called by <Anonymous>() @ CompletedEnemies.js:2460. This function contains only one line which assigns to the src property of an image, and that's the line I pasted.

[0] https://developer.mozilla.org/en-US/docs/Performance/Profili... [1] http://nightly.mozilla.org/ [2] https://addons.mozilla.org/en-us/firefox/addon/gecko-profile...

  this.img.src = this.img.src.replace(/Fish[a-zA-Z0-9]\./, "Fish"+this.direction+".")

It looks like this line is executed on every frame for all fish in the level. For Firefox users who have the Ghostery addon installed, this makes things rather slow because every setting of the src property invokes Ghostery to check whether or not it wants to block the image load.

Granted, that should be another reason for me to uninstall Ghostery, but I wanted to let you know.

1 happens, as long as the bigger part of the window is on the non-Retina display. If the bigger part of the window is on the Retina display, the window only gets a Retina paint event and the non-Retina display shows a downscaled version.

Source: manual testing under 10.7.4 with HiDPI resolutions activated using QuartzDebug