So it turns out, now that Alice got the awesome nochrome tinderboxes up and running, that the Mac, on raw HTML layout, is about as fast as Windows.  However, on win32 and linux, when you add in the perf hit of drawing the full browser UI (the nochrome boxes just render the HTML in a plain window with no widgetry), is on the order of 5%-10%.  On the Mac, it's around 300%.  Clearly there is something very wrong going there.

After some sniffing around, using a very reduced testcase (that I was working with for another performance issue) I came across the Mac native theme code.  Disabling native theme entirely (commenting out all the calls) gave back all the performance.  So I start digging into it.  I collect a bunch of really weird data --- such as, if I replace a call to HIThemeDrawTrack with a loop calling HIThemeDrawTrack 5, 10, 50 times... the overall time spent in the benchmark doesn't change from 1 time.  At 100 times though, it changes drastically.  The delta between benchmark time and raw time spent in NSChildView's drawRect should remain mostly constant with the above changes, one would think.  But it doesn't.  Going from no native theme rendering to turning it on increases the "unknown" time significantly.

I'm still spending time with Shark (which is, I would argue, Apple's best developer tool -- maybe one of the best developer tools, ever), but the latest is completely baffling and what prompted this post.  I finally got around to doing a shark System Trace, which traces at the user/kernel boundary, recording syscalls, preemptions, etc.  In the syscall log, I noticed a bunch of calls to geteuid, getuid, etc., all being repeated.  Looking at the call stack...

... you guessed it.  HIThemeDrawTrack makes syscalls.  For every single call, it calls geteuid, geteuid, getuid, geteuid, stat64, stat64. That's 4 geteuid/getuids and 2 stats.  For every single call to the theme function. This is ludicrous.  The stack traces indicate that this is because this function seems to pull out user preferences on each call, and then has to check if the preferences should change because the euid may have changed (?!?)... the getuid call is coming from _CFUserName.  Because, you know, drawing a UI element needs to know the user name.  It's probably also allocating the CFString to hold it.

I wish this was a joke, but it's not.  I'm now looking into how to draw this crap faster; the NSCell API may be a better way to go -- we'll see if it has this same damage.

I just finished Uncharted: Drake's Fortune for the PS3.  Overall, a very well done game; felt a lot like the Tomb Raider series, but with more shooting and fewer puzzles.  I tend to prefer the opposite mix, but with the difficulty set to Easy, the shooting bits weren't annoying.  The story is pretty good, and the voice acting is the best that I've seen in a game in a long time.  The characters sound and act believable, which is impressive.  Great graphics, no framerate issues, and I never had to load from a saved game -- the checkpoints are well-spaced and if you die, restarting from the checkpoint is instant.  If you're looking for a game to spend an hour with now and then (there are 21 "chapters" that flow into eachother, each one taking probably an hour or so to complete), it is definitely worth a look.  Not a whole lot to say, really.

You're probably not going to see me do too many of these types of posts, mainly because I hardly ever finish games, but I figured I'd start blogging about the games that I've played and do a mini review of sorts.

One of the things that's always been different between the Windows and MacOS X versions of Firefox is favicons on the bookmarks toolbar --- Windows has 'em, the Mac doesn't.  I think the origins of this are from Safari's decision to not include them, but I'm not really sure.  Either way, this drove me nuts... I have a bunch of bookmarks on there where I have the title deleted, so that just the favicon shows up.  This, as you can guess, isn't entirely useful if the favicon is hidden as well.

Luckily, you can restore the favicons with a quick userChrome.css hack.  Here's what the end result looks like:

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

.bookmark-item > .toolbarbutton-icon {
    display: -moz-box ! important;
    background-position: 0px 1px !important;
}

.bookmark-item:hover > .toolbarbutton-icon {
    background: url("chrome://global/skin/toolbar/toolbarbutton-customhover-mid.png") repeat-x;
}

.bookmark-item[container]:hover:active > .toolbarbutton-icon,
.bookmark-item[container][open="true"] > .toolbarbutton-icon {
    background: url("chrome://browser/skin/bookmark-open-mid.png") repeat-x !important;
}

(or, "If I only had a nickel...")

I needed a permanent Linux machine to do some recent bugs; I have a Mac Mini here that's been a champion for the past few months, triple-booting between Linux, OSX, and Windows XP.  But, lately, I've been needing to switch between Windows XP and Linux quickly, so I decided to fire up this Dell Dimension 8100 I've had sitting next to me (powered off) for a while.  I figure it was old enough (over a year, maybe more?) that there should be no problems.  Alas, it wasn't to be.  I installed Ubuntu 7.10; I got some display corruption in the installer, but that went away when I rebooted the installer in "safe graphics mode".  That really should've been a warning to stay away, but I figured that it was just some quirk of the installer and it'll fix itself.

So.  Things install and boot up.  The display is in 1680x1050 instead of 1920x1200, but I don't care.  This machine has a Radeon X300 SE in it, nowhere near the latest and greatest.  I figure, ok, I'll install fglrx; people have been telling me how things are looking up for ATI's driver since AMD took them over.  (Which isn't hard -- it's not hard to improve when you've been releasing a terrifyingly awful driver for years.)  Enable restricted drivers in ubuntu, fglrx gets installed, I reboot, great!  Everything looks good.

But there's a twist. (Ahem.)  My monitor is rotated 90 degrees; this is my secondary monitor that sits to the left of my main one.  On the Mac Mini (using Intel's drivers), a simple "xrandr -o left" fixed things up nicely.  Not so much here.  fglrx hasn't heard of XRandR.  Okay, let's give up on fuglyrx; clearly there's been loads of hype and very little substance there.  I don't care about 3D accel at this point, I just want something that works, so I can get on with my work.  I go back to the radeon driver.  Woo, xrandr shows multiple supported rotations!  Ok, a simple "xrandr -o left" and.... well, the display gets rotated.  Half of it gets corrupted.  Moving windows around is measured in seconds per frame.  This isn't going to work.

Then I proceed to fiddle with Xorg configs, thinking how could this possibly not work, there must at least be a simple way to force a rotation in xorg.conf.. but after about 20 minutes of going through random wiki pages, mailing list archives, etc., I realize I have better things to do.

So, instead, I'm going to go back to either running Linux in a VM, or setting up Xvnc and using that as my X server (which, of course, means I don't get RENDER... hmm, maybe I'll have to use Xephyr and xserver-vnc or something).  If anyone wants to know why working with Linux on the desktop is a pain in the ass, here's a good start.

Oh, and sound doesn't work.

Rob Sayre just checked in bug 411365, which adds some global functions to JS for starting and stopping profiling using Shark on OSX.  This makes it extremely easy to get a clean profile for a specific testcase, especially if the action is deep in the UI or otherwise hard to isolate.  Shark is pretty awesome overall; it's by far the best profiling tool I've used on all three of our main platforms.  The oprofile/syspof based tools on Linux can obtain much the same raw information, but Shark's analysis and data mining tools blow oprofile's tools away.  On Windows I've only used VTune, which always manages to disappoint me.  There's a lot of functionality there, but somehow none of it ever helps me actually solve problems (unless I was microoptimizing a tight loop at the instruction level or something, I guess).