Hacker News: mstange

New comment by mstange in "Box to save memory in Rust"

mstange — Sun, 26 Apr 2026 23:37:30 +0000

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"

New comment by mstange in "Firefox has surpassed Chrome on Speedometer"

mstange — Tue, 18 Jul 2023 13:50:38 +0000

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.

New comment by mstange in "Pines – Alpine and Tailwind UI Library"

mstange — Thu, 13 Jul 2023 02:36:47 +0000

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.

New comment by mstange in "DWARF-Based Stack Walking Using eBPF"

mstange — Tue, 29 Nov 2022 22:21:40 +0000

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...

New comment by mstange in "What rr does"

mstange — Sat, 04 Jun 2022 16:14:49 +0000

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.

New comment by mstange in "Memory leaks are crippling my M1 MacBook Pro"

mstange — Sun, 07 Nov 2021 20:27:22 +0000

Oh, you're right. I missed that.

New comment by mstange in "Memory leaks are crippling my M1 MacBook Pro"

mstange — Sun, 07 Nov 2021 19:34:03 +0000

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)

New comment by mstange in "14kb WASM game written in D"

mstange — Tue, 14 Sep 2021 15:10:12 +0000

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

New comment by mstange in "What happened to Firefox Send?"

mstange — Fri, 18 Sep 2020 18:20:54 +0000

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

New comment by mstange in "Upcoming Firefox update will decrease power usage on macOS by up to three times"

mstange — Wed, 04 Sep 2019 18:02:12 +0000

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.

New comment by mstange in "NSTouchBar API Reference"

mstange — Fri, 28 Oct 2016 03:52:15 +0000

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.

New comment by mstange in "Multi-process Firefox brings 400-700% improvement in responsiveness"

mstange — Tue, 06 Sep 2016 18:37:41 +0000

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

New comment by mstange in "Multi-process Firefox brings 400-700% improvement in responsiveness"

mstange — Tue, 06 Sep 2016 18:33:26 +0000

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

New comment by mstange in "My time with Rails is up"

mstange — Sun, 22 May 2016 18:04:41 +0000

Thanks!

New comment by mstange in "My time with Rails is up"

mstange — Sun, 22 May 2016 17:47:37 +0000

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

New comment by mstange in "Reason: A new interface to OCaml"

mstange — Tue, 17 May 2016 21:39:05 +0000

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

New comment by mstange in "Full-fledged FPS in WebGL"

mstange — Wed, 14 Jan 2015 23:45:34 +0000

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.

New comment by mstange in "Humble Mozilla Bundle"

mstange — Tue, 14 Oct 2014 21:29:59 +0000

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.

New comment by mstange in "Show HN: I spent two years working on an HTML5 game. I finally released it"

mstange — Tue, 23 Oct 2012 12:43:41 +0000

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 () @ 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...

New comment by mstange in "Show HN: I spent two years working on an HTML5 game. I finally released it"

mstange — Mon, 22 Oct 2012 22:06:57 +0000

  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.