Thursday, August 29, 2002

Quartz Extreme comment It seems that a lot of folks are disappointed with Quartz Extreme because it doesn't accelerate window resizing. QE accelerates two primary features of the Aqua UI. First, it accelerates the rendering of a number of the special effects throughout the UI-- shadows, window zoom animation, the dock, etc... The second focal point of acceleration is the management of the backing store of the windows on the desktop. That is, every window in the Aqua/OS X environment is generally (doesn't have to be) backed by an off screen buffer that contains the current pixels for the entire window. When hunks of a window are exposed (say, when you drag Mail's window and a chunk of a Finder window is exposed because it was underneath), the exposed window doesn't have to redraw. Instead, Aqua grabs the already rendered pixels from the offscreen bitmap and blasts them to the screen. Much, much faster than context switching in the application and asking it to re-render the same stuff. As an aside: Applications can ask to receive notifications when a part of a window is exposed. I.e. an app can explicitly ask the window server [Aqua] to give it an oppurtunity to redraw a window's contents if that app deems it necessary. Back to QE: On a system with Quartz Extreme enabled, QE moves all of the backing store bitmaps that it can into the 3D accelerator card's (the video card) memory as a set of textures. Each window is basically a 3D texture. As such actions that involve moving windows around the screen-- be they because of a user drag event or because of some animation-- operate much more quickly because it can mostly be done as a series of texture compositing operations on the video card directly. This is much, much faster than doing all of the compositing in main memory and blasting the final bitmap out to the vid card afterwords. In effect, QE treats the user's desktop as a 3D scene. What this means, though, is that Quartz Extreme has little influence on the performance of resizing a window. When a window is resized, the application has to render the contents of the window to reflect the size change. Often, this is much more complex than simply rendering the exposed bits in that controls may move or need to be redrawn to reflect the new size. QE does not affect how an application generates the pixels that are drawn into a window. Once the pixels are generated-- once a window is drawn-- Quartz Extreme takes over the task of optimizing the heck out of managing the resulting window. 12:17:45 PM

Painful. The hard drive in my TiBook died today. Not a total death, but one of those really annoying, happens right in the middle of upgrading about 17 things on the system while in preperation for a demo, kinds of HD failures that suck about 10x more time/life out of you than they should. It all started yesterday sometime after a WebObjects upgrade (coincidence). The system started to lock up for 30 seconds to a couple of minutes every once in a while. I chalked it up to lookupd stupidity, WO services oddities interacting with sleep, or multiple-monitor / network connection bogosity across sleep events -- all things that have caused similar symptoms in the past. Until this morning. The symptoms had gotten a lot worse -- to the point where the system was on unstable with a single network connection and no sleep events. Very suspicious. But, then, total confirmation happened. The hard drive-- an IBM 48GB 2.5" TravelStar-- emitted a sound now hard drive should ever make. Imagine a busy signal about 10x louder than any phone could produce. Now, imagine that coming from a device that doesn't actually have a speaker built into it. Nuts. I have relatively decent backups of everything, but not as full images because of both cost and wasted effort backing up a bunch of stuff that is totally transient. So, no data loss. But what a pain to restore the laptop to working order! I had to replace the IBM drive with a Toshiba 30GB -- 4200 RPM vs. 5400 RPM. Yuck -- can definitely feel the speed difference. Since the whole thing was so painful anyway, I decided it would be a really good time to toss my old preferences and start over. The preferences on my system originated under NeXTSTEP 3.3 and have been auto-upgraded many times across many versions of the OS up to OS X 10.2 -- lots of oppurtunity for oddities in that history. If this post works, Radio survived the transition. That Radio hardwires everything into the app directory in the fashion that it does is inexcusable. What a pain in the ass to deal with in any kind of an environment that changes over time! So -- only 12 or so hours lost to stupid machine problems... 12 hours lost in the 36 hours leading up to a fairly critical demo of which I am responsible for the Web Services part of the demo which is the cutting edge piece. Riding tandem with the random.... 1:47:29 AM