I always read John Siracusa’s review of the latest Mac OS X release with great interest, and he always delivers. Such is the case again with his review of Mac OS X Snow Leopard, which is of particular interest as for this release Apple teased only “one new feature” (Microsoft Exchange support), and John does a bang up job showing the other, non-obvious new stuff in this release (as obviously the guys writing Mac OS X did not just stop working for nearly two years).
That being said, there are a few things that I either heard about before, or learned about afterwards, that I wish he would have covered in the review. This isn’t necessarily a reproof of his review, as he has to make choices as to what he covers, and he can’t be aware of everything anyway. Nevertheless, here are a few things I wish I could have read about in his review.
John does of course cover QuickTime X, but there is some more interesting stuff I found out about it.
First, the offloading mechanism he describes, where videos that QuickTime X cannot handle are played in a QTKitServer process, is not sufficient for all cases: there are videos that the new QuickTime Player app cannot even handle and have to be opened by QuickTime Player 7. This is why, when you install QuickTime Player 7 (which is an optional install), video files become owned by a “QuickTime Player Launcher” app (which lives inside QuickTime Player 7), and whenever you open a video this app dispatches the video to the new QuickTime Player, or to QuickTime Player 7 if the former cannot handle it. It’s safe to say that Apple has you covered for this transition.
Second, another feature not supported by QuickTime X at this time is video orientation, which is surprising since it is used by the video recording feature of the iPhone 3GS; as a result, if you have videos recorded in tallscreen from your iPhone, the new QuickTime Player will play them rotated 90°.
Third, contrary to what he implies in page 5: “the most significant new 64-bit-only API is QuickTime X”, 32-bit apps can use the QuickTime X engine; indeed I know of a bug in the traditional QuickTime playback engine, which I can reproduce easily in QuickTime Player 7, but cannot with the new QuickTime Player, whether it is running in 32 or 64-bit mode.
libcache is an interesting new functionality from the lower levels of Mac OS X. Back in the days of classic MacOS, memory had to be much more explicitly managed, and one of the ways it was done was with purgeable memory buffers which could be freed by the operating system if it needed the memory; a common pattern was loading data from a file in such a buffer, if when coming back to it the application found the data still there, all the better, otherwise it would simply allocate the buffer again and reload the data from disk. The Mac OS X virtual memory system and memory-mapped files advantageously replace this pattern and purgeable buffers are never purged on Mac OS X. However, a use case for which there was no longer a solution is the following: what about data which is computed from other data and cheaper to recompute than to save then reload from disk? An application willing to cache this data either doesn’t, and wastes performance recomputing it each time, or keeps it in memory, and if this data gets paged out to disk when the application then tries to use it again the virtual memory system wastes time reloading it from the pagefile as the application could have recomputed it more quickly instead.
Enter libcache. With libcache programmers can attach data to a cache object and libcache will call a release callback on the data object if memory needs require it. This functionality is also available at the Foundation level, and Foundation also provides an equivalent of the purgeable buffers of old with NSPurgeableData.
This is not too frequent but still a pattern I see with Mac OS X: it generally introduced significantly easier ways of doing common operations, replacing mechanisms from classic MacOS which needed much more manual management, but some special use cases ended up not being well-served by the new Mac OS X way, and Mac OS X ends up rediscovering and supporting these some time later. Grand Central Dispatch, interestingly, is the exact converse: a massively simpler way to leverage functionality (here, multicore processing) that will ensure this functionality will end up being actually used in much more software, improving performance and user experience across the board.