njr 3.0

Mike Pinkerton (whose weblog I don't read regularly because it doesn't have a syndicated version I could find) complained about nobody at MacHack using Mozilla on their TiBooks. I find Mozilla barely usable on my dual G4/533 and G4/800 TiBook—to the point I use it as my primary Web browser, and have for months—but unusable on a G4/400. That might be part of it: not everyone can afford the latest hardware to run their Web browsers on.

Pink also complains that there aren't enough external Mozilla Mac developers. I've tried, on several occasions, to contribute; most often I just get ignored or yelled at that I shouldn't be doing something. While the few Mozilla/Netscape developers I know personally are quite nice (as were those I met at MacHack—there was a huge Netscape contingent there: scc, pink, smfr, brade, dagley, and another?), the whole development process seems amazingly cliquey and resistant to people who don't have their entire lives to give over to the greater good that is Mozilla. Scott Collins was bragging on #mozilla about his 23" Cinema HD display. Then as now... *drool*. I gotta get me out of school so I can afford this stuff again.

Which leads me back to work. I'll get back to DockCam next weekend if miscellaneous festivities don't overwhelm me.

9:52 PM | Radio
No Comments

I switched to CURLHandle—an extremely painless experience. CURLHandle replaces NSURLHandle without your needing to do a single thing to your code. But CURLHandle leaks memory too. It leaks a lot less: a CFMachPort, CFRunLoopSource and two CFBags. I was able to remedy the problem by only creating a CURLHandle when you change the image URL, which won't be too often.

I am now out of stuff OmniObjectAlloc can help me with: the continuing leaks don't register. Yet I'm still leaking 50K per image load! I commented out the image drawing, then the image loading, then the status window notification, so about all the app does is load a URL on a timer, and it still leaks.

So, DockCam is on hold until I resolve this last remaining issue. I've fixed the rest of the bugs, and some more I discovered along the way. Right now I'm trying out MallocDebug.

3:51 AM | Radio
No Comments

Subpixel rendering in Jaguar. Perhaps my eyesight's too good or something? I can see the color fringes when looking at the screenshot on my TiBook. While it's obviously smoother, it is somewhat disconcerting.

Not sure I like the new Aqua theme very much. It's too glassy, which I guess is the point… but the popup menu arrows and the gigantic window sizing corner have to go.

(Note: Bill Bumgarner points out that these screenshots are in GIF format, so they've lost something in the conversion to a 256 color palette. To me, both Jaguar's font rendering and the revised Aqua theme look much better on my CRT at work than they do on the TiBook's LCD; go figure.)

10:14 PM | Radio
No Comments

Panic is publiclyprivately (a download URL leaked out) testing betas of Audion 3.0. It has a lot of useful-looking features including better streaming and recording. But this abomination persists:

If you haven't used Audion, care to identify any one of these toolbar icons? (Note: the toolbar isn't customizable to show text as well as icons.)

4:51 PM | Radio
No Comments

Er, so much for the DockCam release. Still remaining on the to-do list:

• Every other time you open Preferences, the focus changes
• Fix return in combo box not triggering default button
• Check that we aren't leaking NSURLHandles (or anything else for that matter)

The first issue is a bug in my pref handling code which I haven't tracked down; the second is a bug in NSComboBox which I can probably work around, and the third is what I've spent the past two hours trying to figure out.

According to the indispensible OmniObjectMeter, I'm leaking primarily NSConcreteMutableData and NSHTTPURLHandle objects. Watching my process's memory usage, it grabs about 500K per image load. But if I stop the timer which triggers image loading, lots of memory is freed, and the leaks have dropped to about 10K per load. There's an autorelease pool that is waiting for me to stop, but my program isn't designed to do that.

The NSConcreteMutableData objects are being retained by the NSHTTPURLHandle objects, ironically inside a method called 'flushCachedData'. Some flushing it's doing!

The retain-release cycle of a NSHTTPURLHandle object looks like this:

• alloc in my code, from -[NSURL URLHandleUsingCache:]
• autorelease called inside -[NSURL URLHandleUsingCache:] (makes sense…)
• 2 retains in -[NSURLHandle loadInBackground], called by my code
• release in my code, because I explicitly pop the autorelease pool used by -[NSURL URLHandleUsingCache:]
• release in the stream read callback, -[NSHTTPURLHandle performStreamRead:]
• autorelease in the stream read callback
• release in -[NSApplication run]

The problem is that the final release is never triggered until the application is quiescent: when I stop the timer that causes the image to reload. For the moment, I'm stumped. My only thought is to switch from NSURLHandle to Dan Wood's CURLHandle in the hope that it will let me control its allocation behavior.

4:58 AM | Radio
No Comments