1
2
3

git bisect start
git bisect bad 123abc  # skip the commit hash if you want to mark the current position
git bisect good 234bcd

The other day we discovered a really bad bug that in some special circumstances hogged down the web browser tab so much that it had to be killed. I was happy Firefox recently split up the page contents and browser UI in different threads.

We knew we didn’t have this problem before but how could we find where the bug had been introduced without doing a lot of manual labor? Then I remembered a git command that a colleague on a former project was praising regularly. It was git bisect.

For hardware accelerated content in Chrome, you can get the number of painted frames per second by switching it on in about:flags.

Firefox also has a flag like that (layers.acceleration.draw-fps in about:config) but it seems a bit shaky. I have gotten it to work on Firefox Mobile but not on desktop (only tried Linux and Windows though). For Windows there is a fixed bug that is targeted for Firefox 32. And on Linux, hardware acceleration is generally problematic as I understand it.

Therefore I wanted to write an FPS counter that worked even if all the constraints were not fulfilled. So here it is, a simple FPS counter that places itself in the bottom right corner and updates about once a second.

Looking at how good the largest web browsers are today compared to how the situation was some years back, it’s easy to be fooled that they all behave the same when they “follow the specifications.” That is not really how it works though. Even when strictly implementing a standard there are choices to be made. This has as a result that in some situations different browsers have different behaviors even though they adhere to the same specification.

Recently I ran into two of these situations and got stuck since I hadn’t been reminded for a while that these differences exist.

This is my first technology blog. I’m starting it for two reasons. The first is that I somehow hope that it can be of help to people having the same problems that I do or that want to learn more about the technologies I write about. The second reason is to help myself getting better through explaining the subjects to others. They say you don’t really know something until you do that.

Oh, I have a third reason too. I think it’s going to be fun!