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.

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.

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

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.

Thanks!