Cocoadex

Natural User Interface Group

Recently, as you may have noticed, I've gotten into working with multi-touch a lot. It's a common focus among modern HCI experts, and as many people would agree, it seems to be the direction we are heading in the field. While some would argue that the technology is far from mainstream, one group in particular is working towards fixing that in the best kind of way -- open source.

The Natural User Interface Group is a group of like-minded individuals working towards making multi-touch surfaces more mainstream. They've got a lot of open source software and step-by-step guides to making multi-touch surfaces, and getting software up and running with them. In addition, they've got a great IRC channel on freenode, #nuigroup where a lot of friendly and helpful people hang out answering questions and talking multi-touch. I stopped by after getting an comment on Photo Touch from one of their members, and ended up staying way later than I should have discussing multi-touch.

In addition, NUIG is a Google Summer of Code group this year, so I encourage anyone still looking for a group to submit an application to, to definitely check them out. One individual, who has been working on NUIG related things with regards to Cocoa is Bridger Maxwell. He and I talked at length about some more in depth multi-touch capabilities coming to Cocoa as apart of his proposal to the NUIG for this year's summer of code. Hopefully, he'll get accepted, and he and I can work together to bring some better support for Mac OS X, Cocoa specifically, in the open source multi-touch world. Like Bridger says on his blog, Cocoa provides a lot of great tools for data visualization and allows developers to create amazing looking graphics code with a fraction of the code of other platforms.

If you are interested in multi-touch, and the possibilities that are out there, you should definitely check this out. If these rumors are to be believed, we might all be writing multi-touch code much sooner than we think.



That's rich.

FCC to turn down Skype's mobile open access plea: "The FCC plans to dismiss a request from Skype that would require mobile operators to open their networks.

Skype? Wanting someone to be more open? Are you serious? Get back to me when you open your own software up to third parties, then you can go back to writing petitions for other people to open up their own.

(Via Macworld.)

"Custom" Multi-touch Gestures with MultiClutch and Safari/WebKit

Back again? So soon you say? Of course!

MultiClutch is a great program by Will Henderson which allows you to assign a keyboard shortcut to be executed when you perform a gesture on the trackpad. This proves immensely useful for providing improved gesture functionality to applications.

It should come to no surprise to you dear reader, that the initial functions for the gestures currently in Leopard slightly...well, dissatisfy me. I'm of the opinion that multitouch should be more than just bindings for keyboard shortcuts, but since I have no control over that, I'd at least like the shortcuts to be useful ones. So, with that in mind, I offer up my highly improved (in my own opinion of course) bindings for WebKit/Safari (They will work for both, but you have to bind them for both.)

Let me translate for you dear reader.

Zoom In is the pinch gesture, and it closes the current tab, or window if there is only one tab. This is the only dangerous one, since it's pretty easy to do the pinch gesture when you are scrolling. This can cause some faulty tab closures, which is annoying, and I'm habituated to hitting Cmd+W, but sometimes when I click and link and get a new window, it's really nice to be able to pinch it away.

Zoom Out is the zoom/expand gesture, and it opens a new tab. I use this ALL THE TIME, and really think it should be the Safari default instead of text size, but hey, what do I know?

Swipe Up and Swipe Down go Forward and Backward respectively. I liked these at Left/Right, but not as much as I like changing tabs (What Swipe Left and Swipe Right are bound to) with left and right, and I do that a lot. I understand that the gesture mimics the buttons, but again, I think Forward (Up) and Back (Down) make more spatial sense.

Finally, my favorites. Rotate Right is Cmd+R, which is Refresh. I maintain that I came up with this independently of Jesper, but whatever. It's awesome, and every app that has refresh should use it.

And now, the trump card. Safari 3 added a menu option called "Merge All Windows" which merges every open window and all their tabs into a single window. Similar to above, sometimes I use those pop-up'd windows to continue my browsing, which means I get several windows with several tabs each. This is annoying, and happens frequently enough. However, this has no keyboard shortcut! So sad.

Mac OS X makes this easy however, using "Keyboard Shortcuts" under Mouse/Keyboard Preferences.

You can see that I've added a keyboard shortcut "Cmd+Shift+M" to merge all windows to Safari. NOTE TO WEBKIT USERS: IF YOU USE WEBKIT NIGHTLIES IT STILL GOES UNDER SAFARI. THAT IS ALL. After I've done this, I can easily bind a MultiClutch gesture to do this, and that's just what I did.

So that does it. Let me know what you think in the comments, or on Twitter or something. Also, let me know what other bindings you have for applications.

BONUS: Adium implements gestures in 1.3. They are awesome! Thanks to Zac West for them.

Photo Touch

Long time no see blog!

However, I've been busy. Today, I'd like to show everyone one of my final projects for school, which happens to be a multi-touch demonstration using my new Macbook Air (awesome) and Core Animation (also awesome). It's called Photo Touch, and I'll go ahead and let the video do the talking.

Hope you enjoyed that. I'll be back with more real soon. Like I said in the video, hopefully the code will be available after the presentation on the 11th of April. Wish me luck!

Thanks again to Patrick Gibson, Jefferson Han, and Scott Stevenson for their contributions to Photo Touch. (Photos, Ideas, and NanoLife Random Path code respectively).

Macbook Air vs. iPhone: A Multi-touch Mystery

Continuing my theme of Macbook Air trackpad related posts, today we're going to look at some intriguing differences in behavior between the trackpad and the device that made multi-touch all the rage -- the iPhone. The particular behavior I'm talking about is the swipe behavior in Preview.app. The behavior in Preview is obviously an attempt to mimic how the iPhone allows one to browse through all of the open documents in Preview. In this example we'll use a group of photos to exhibit both behaviors.

Let's start with the iPhone.

On the iPhone, the idea is that the user is reaching out and touching the photo, and "flicking" it to the left or right. So, let's say you reach out to the right side of a photo, and slide your finger to the left. The image then follows your finger, sliding off to the left, and the next image slides in from the right. This is pretty expected -- you have flicked the photo off the screen to the left, and it follows your finger off the edge of the screen. Even if you reach out and touch the middle of the photo and flick just a little bit to the left, the same expected behavior happens. You've grabbed the photo, pushed/flicked it off to the left, and a new image comes in from the right. Of course, the images aren't unlimited and if you attempt to do this when there is not a next image the image attempts to move off to the left, and then bounces back to show you that no image to the right exists, and that you are at the end. This all makes perfect sense, is pretty intuitive, and seems like the logical behavior to model the swipe behavior in Preview after, right?

Apparently not.

As an iPhone user, I approached the Macbook Air with a great bit of excitement. While the applications that currently support gestures don't exactly make me jump for joy, the potential for these gestures in third party applications is simply put, awesome. However, I'd at least expect some consistency between the two platforms.

Unfortunately, Preview falls short.

In Preview, swipes aren't as sophisticated, and in my opinion, not as well thought out as on the iPhone. Instead of the reaching out, touching, and flicking metaphors that work so well on the iPhone, swipes on the Macbook Air's trackpad simply move in the direction of the swipe rather uninterestingly. Sure, they animate nicely, taking full advantage of Core Animation, and when they reach the end of the set the image bounces back. However, Preview decides that reality, and thus platform parity, should fly out the window.

A swipe to the right in Preview, moves to the photo to the right. A swipe to the left in Preview, moves to the photo to the left. This is the opposite behavior you'd expect if you've ever used an iPhone, and sure enough, the opposite behavior I think you'd actually want. Using a multi-touch trackpad is not analogous to using the arrow keys. I'm not trying to arrow through my pictures, my mind is expecting a higher level experience -- I am reaching out and literally swiping through my photos, just like I might turn the pages of a book. Similarly if I rotate, or magnify my pictures, I'd be expecting the computer to act like I'm picking up a photo, and pulling the photo closer to me respectively, and indeed this is what happens.

Now then, it's possible that this functionality is actually intended. If we look at another application that implements multi-touch capability, the current behavior is actually correct. In Safari, moving to the right should in fact send us forward, and moving to the left, should send us backwards. That makes sense after using it a couple of times. There are thus two arguments that can be leveraged for the case of Preview's behavior. The first is system parity. Other applications act this way, thus, Preview should as well. I'm guessing that's the one they chose, and that's why it's implemented this way. I argue that is should be changed, because it just feels wrong. Even more so after you've used an iPhone for about two minutes. The second reason, is that Preview is not necessarily running a full screen context. Thus, the idea of flicking pictures isn't especially clear. However, I get the feeling that's exactly what they were attempting to mimic. When you reach the end of a set of photos, the image has a nice bounce effect, just like on the iPhone. However it bounces the wrong way! That's right, when you get to the end of a group of photos, and continue to scroll as if another photo should be there, the image slides to the right and then bounces back. This is completely wrong. Since the photo should be sliding off to the left, it should do so, and then bounce back, very similarly to how the iPhone works.

I think this ultimately shows one of the interesting aspects of these trackpads being integrated into our computers. It's very easy to get confused about how they should work. Multi-touch shouldn't be just an alternative way to arrow through things. It's an advanced and sophisticated input method, and requires programmers to really think about how users are going to interact with their computer when using gestures. Assuming Apple continues to integrate this technology into their laptops, we will soon be at a point where multi-touch is a big deal. Both platform parity and system parity need to be considered, but more importantly a great deal of thought needs to go into this process, and whether through guidance from the top as to how users should be expected to interact with the multi-touch trackpad, or through a standards system of our own, right now it's up to the developers using the technology to shape the way users use this technology.

All in all, there are far more iPhones and iPod touches around than Macbook Airs. Far more people are going to be used to using these devices, rather than a Macbook Air, and thus I think it's clear the paradigms we should strive to mimic.

Peter Hosey has pointed out, and I agree with him really, that Safari should mimic the iPhone behavior as well. After all, who doesn't want to flick through webpages?

Bugs have been filed on Preview and Safari: here and here.

Ciaó

⌘

NSResponder Modifications: Swipe, Rotate, and Magnify

So, I'm sure you've heard of the Macbook Air and it's revolutionary multi-touch trackpad, borrowed from the iPhone technology. The basic gist of it is that it provides application specific gestures that can be triggered by performing some gestures on the new trackpad. With that in mind, every Cocoa developer should be asking themselves this question: What has Apple done to NSEvent [and friends] to facilitate gestures in their own applications and how can I do it in mine?

With the help of my local Apple Store's Macbook Air, and some NSEvent knowledge, I'm going to answer exactly that.

Alright, since we're dealing with what are presumably new events, the first place we should check is the system version of NSEvent, hoping that maybe, just maybe Apple has defined them for us. Since this a blog post of decent length, you can infer what I did -- they aren't documented at all. Hooray.

This is furthermore supported by a small test application that I wrote which logs all of the events coming out of NSApplication by replacing my NSPrincipalClass key in Info.plist with the name of my subclass of NSApplication - GestureTest. By overriding -(void)sendEvent:(NSEvent *)anEvent, and logging every event that comes out, I can get a quick overview of every single event that gets passed to my application. This is very handy in a lot of situations, particular this one. Upon closer inspection, we have five new events - three events for each gesture, and two events corresponding to the beginning and end of a gesture respectively.

The gestures are as follows, grouped with their corresponding NSEventType.

BeginGesture: 19 (I think, I forgot to double check this, woops!)

Swipe: 31

Magnify: 30

Rotate: 18

EndGesture: 20

Since these events are standard NSEvents, they are affected by flag modifiers (i.e. we can differentiate between a swipe with Command held down and a swipe with Command-Option held down).

Thus, we have a basic way to check for these events -- we can check the flag and handle gestures appropriately. However, this is pretty inefficient - we have to check every event for this type and it isn't very flexible - we have to intercept at the NSApplication level. No good.

If you recall from Chapter 16 of Aaron Hillegass' excellent book Cocoa Programming for Mac OS X (Preorder the third edition here), every object that is going to respond to events needs to descend from NSResponder. NSResponder implements the public interface for responding to various mouse and keyboard events - our good friends -(void)mouseDown:(NSEvent *)anEvent, -(void)keyDown:(NSEvent *)anEvent, and friends. However, this documentation hasn't been updated for the Macbook Air, and as expected, the header does not reveal any additional information about these new events.

However, we have a solution for this. Steve Nygard's excellent class-dump which allows us to inspect a particular framework for it's symbols. Naturally, being the curious person I am, I ran this against the Macbook Air's version of AppKit (949.18.0 if you're curious). After a short wait (AppKit is very large after all), the results poured out into a freshly pressed text file. I immediately searched for the word "swipe", chosen completely at random. What I found, was worth it's weight in gold... assuming you want to implement gestures.

- (void)magnifyWithEvent:(id)fp8;

- (void)rotateWithEvent:(id)fp8;

- (void)swipeWithEvent:(id)fp8;

- (void)beginGestureWithEvent:(id)fp8;

- (void)endGestureWithEvent:(id)fp8;

These new methods belong to NSResponder, which means that every single responder now supports these gesture events. That's pretty awesome. My immediate reaction was to set symbolic breakpoints for these symbols and to perform some gestures using my little test application. As expected, they were hit, and I checked out the backtrace. The only thing of interest was a new private method for NSApplication -- _handleGestureEvent:

called from NSApplication's -(void)sendEvent:(NSEvent *)anEvent method.

Just to confirm this assumption, I overrode this method and just logged events from it. Turns out the only events that come through this method are gestures. Awesome. Interestingly enough, there is a small observation to be made here. Since every gesture passes through here, one could actually replace these gesture events with any other event, so you could get some free custom gestures by replacing the gestures with say, a keyboard shortcut event before passing it down the responder chain. Nothing really fantastic, but nice to note if you feel like playing with private methods.

So finally, we have everything we need to implement gestures for any NSResponder based object. Simply override the appropriate method for your gesture (swipe, pinch [magnify], or rotate), you can grab the value out of the NSEvent using the corresponding methods:

Swipe : -(float)deltaY; -(float)deltaX;

Magnification : -(float)deltaZ; -(float)magnification;

Rotation : -(float)rotation;

These methods return various values for each type of event depending on the type of event, velocity of movement and/or direction of movement. Some interesting notes here - swipes can be detected to the left or right as expected, but also up and down. Pretty cool. I also suspect that the two methods under magnification actually return the same value, but I haven't checked. The value logged with the event is deltaZ, however. Rotation is pretty self explanatory. The actual values these methods return is a little bit more of a mystery. Swipe is straight forward, 1.0 for right, -1.0 for left, 1.0 for up, and -1.0 for down, depending on whether you check deltaX or deltaY respectively. Magnification and rotation both return various positive or negative values depending on the rotation or scale of magnification. You'll just kind of have to play with these, I couldn't discern a good pattern. However, there are two methods on NSEvent: -(float)standardRotationThreshold and -(float)standardMagnificationThreshold which I'm sure return some magic values that allow you to determine the angle and scale for the gestures, which I imagine can help you figure out what you need to do to your responder as a result of the gesture. Additionally, NSEvent adds -(BOOL)isGesture, which as expected, lets you determine if an event is a gesture. NSResponder also adds gesture masks via -(unsigned long long)gestureEventMask and -(void)setGestureEventMask:(unsigned long long)aMask which presumably deal with the specific masks regarding events.

So, that should pretty much do it. You should be armed and ready to go to write some amazing code to take advantage of the trackpad inside the Macbook Air, and hopefully coming soon to a Macbook and Macbook Pro near you. Before anyone asks, this code will NOT work on current Macbook models, at least not on the current build of Leopard. It's possible when this AppKit version begins shipping standard (10.5.2, I suspect) that we may be able to fake these events with the old trackpads, depending on how much information we can squeeze out of AppKit.

Finally, I've built a small project based on the all of this code that will allow those of you lucky enough to have your Macbook Air already to see it all in action. It's fairly simple, just filling a simple custom view with a color based on the gesture you perform, but it is set up as a great test bed for playing around with third party gestures. In addition it has a commented out private method from NSApplication to log all the gesture events if you want to see them. Obviously if you uncomment this method, the events won't be processed and the color won't change since it's not sending them down the chain. I'll leave it as an exercise to the reader to add that. ;)

Thanks to everyone at my local Apple Store for their help, and the Macbook Air. Hopefully this will help everyone get their applications ready for multi-touch trackpads before they are everywhere.

Be back soon.

Lemur Math

Mike Lee, of Delicious Monster fame, has a thrown up a tantalizing post concerning Core Animation and lemurs. Being a member of the Founding Troop myself, and an avid lover of OpenGL and Core Animation, I just had to check it out.

Mike offers up a fantastic way of leveraging Core Animation to almost perfectly capture the essence of the Dashboard-liquifying, delicious flips the iPhone pulls off. Now then, while I am totally not the biggest math buff, I do have some background in the mathematics behind computer graphics, so I thought I'd offer up a more in depth explanation of the "Newmanian Physics" at work here.

So, let's dive right in.

Mike begins the breakdown of the actual numbers process thusly:

Luckily I used to work with this insane genius named Lucas, who discovered that if you put a very small value into "m34" of Core Animation's CATransform3D struct, then scale the layer just right, you get a decent facsimile of the iPhone flip.

Since m34 doesn't sound very good in conversation, I think of this at the "Newman factor." The resulting distortion is, therefore, "Newman distortion," and the units in which it is adjusted are Newmans. One Newman is equal to the inverse of the distortion, which I'm pretty sure is math-speak for transform.m34 = 1/distortionInNewmans. In other words, the more Newmans you have, the less the distortion.

If we look at the documentation for the CATransform3D struct (hidden at the bottom of CALayer mind you), we notice that it is simply a struct representing a 4x4 matrix of CGFloats. These are logically numbered as most elements of matrices are - an 'm', followed by the row number, and then the column number. Thus, the Newman factor, as described by Mike corresponds to the third row and fourth column of our 4x4 matrix.

Now then, the more pedantic among you might notice that we are using a 4x4 matrix, and not a 3x3 matrix as would be logical given that we are in 3D space - that is, we are working with x, y, and z components, and that in Mike's example we are actually working with this seemingly useless fourth column vector to produce the desired effect. This fourth column vector (m14, m24, m34, and m44 for those keeping track) is where our adventure starts.

Homogenous Coordinates

So, in math, as in computer graphics, this additional vector constitutes what are called homogenous coordinates. Roughly speaking, this equates to representing an N-D matrix using an N+1-D matrix, in order to capture an affine transform into a matrix form. Since modern graphics APIs work with matrices, modern graphics hardware is designed to work with matrices at a blindingly fast rate. Thus, in order to optimize affine transformations, being able to express them as matrices is extremely important.

Now then, I know what you are saying to yourself. Elliott, what the hell is an affine transformation? Glad you asked! At it's most basic level, an affine transformation is a linear transformation, followed by a translation. Linear transformations in N space are represented by a single NxN matrix. The follow up translation is represented by a single column vector (in matrix form) which is where the additional column comes from. Now then, you are probably wondering about the additional row - this row represents a projection vector.

I'll explain if you are interested, if not, you can safely skip this part, just know that the projection vector is important for OpenGL/DirectX, and that it results in the additional row - and completion of our 4x4 matrix.

Perspective Projection

Now then, the addition of the fourth coordinate (for each column vector, representing a point in space), means that we are technically working as if we were in 4D. This is useful for projection of a 3D scene, as we can refer to any point by it's 4D coordinates (x, y, z, w). Now then, assume we have two planes. We can refer to these two planes by their value of w, as that is the only actual thing that varies between them. So, if we refer to the difference between these two planes in terms of w, let's say, w = 1 for one plane, and w = k for another plane. It doesn't really matter what k is, just that it isn't (or it could be) 1.

Now then, our point can be expressed on either plane using the same x, y, and z coordinates so long as they are expressed correctly in terms of w = 1, that is that w = 1 is the base for the projection. Thus to relate the two points, (x, y, z, 1) and (x, y, z, k) we can simply divide each coordinate by k.

So, we get - (x, y, z, 1) == (x/k, y/k, z/k, 1). Pretty simple right? Awesome. As I said before, for our purposes, this doesn't really matter, but if you are really curious, this is very important in perspective projection, i.e. the effect of an object that is "farther" from you being projected at a smaller ratio. This additional row allows you to model this perspective projection into the matrix model, which, as before, is very useful.

Does Your Head Hurt Yet?

Alright! So now that I've justified to you that 4x4 matrices are necessary, we can continue with this lemury math lesson. Looking back to what Mike talked about, we see that the component at the third row and fourth column is being modified to create this effect. As per above, this corresponds to the additional translation in our affine transformation to the z coordinate.

This actually turns out to be an exact equivalent of a common OpenGL command - glTranslate3f(x, y, z) on the current matrix, which is actually the identity, as per Mike's source code. In addition, this is applied as a sublayer transformation, which means that it affects all of the sublayers on the layer it is set on, but of course, not the actual layer. The layer that this is set on, is in the fact the content view's layer, which means that this transformation happens to -- tada, the images.

But the real question, is what does this actually do? Great question. This is the first part, of a [not-so] tricky two part matrix multiplication. You see, this translation does not in fact produce the actual flip. It is simply a perspective correction in the form of a translation after another component of this single affine transform. That's right, the power of Core Animation and math combine to let you do amazing things with a single transform. Your graphics card can do a freakin' bazillion million of these a second. The other part, coincidentally, is a rotation around the Y-axis, just as Mike discussed Dashboard widgets perform. This matrix is fairly common, and is useful to keep in mind when working with Y-axis rotations.

Where a is the angle of rotation, in our case, 180 degrees or π radians.. So, turning back to the example at hand. The other part of the affine transformation is handled in the form of flipAnimation from Mike's code. This code proceeds to rotate the front view and back view (in this case, two different images) in opposite directions so as to give the sensation of the one image flipping "over" to reveal the other image. As per Mike's post, in reality this would cause the object (an image) to actually move towards us. However, what we expect and what we get aren't quite in sync. Since a computer display is just a projection of these images, we get a rather dull and uninteresting simple y-axis rotation, where we can't actually notice that the image should be moving towards us. If you imagine several planes, each one representing a computer display, the image would have realistically moved between one plane and another plane in the Z-direction (in this case, positive Z, coming out of your computer display, and thus representing the expected forward movement).

@finally

Alright, so now we have discovered the source of the majority of the flip, but remember, we still have that little Z translation floating around. So, if we combine the two to create our final affine transformation matrix, we get a matrix that looks like this. Let's define X as (1/DN).

Where DN is Distortion in Newmans. Now, you might notice that the inverse of distortion in Newmans is actually negative! This is pretty surprising, as Mike definitely set the distortion in Newmans to be the positive inverse of DN. How did this happen? Well, if we split this matrix back into the two matrices that formed them, we get:

For the rotation. And

For the translation. Notice, still rocking the positive 1/DN. However, if you pull out that dusty old Linear Algebra textbook, and run matrix multiplication on these two matricies, you will notice that the negative values in the rotation matrix cause the 1/DN to become negative. In this case, this is interesting because we happen to have a positive Z increase from our Y-axis rotation that is being unrealistically removed from due to the projection onto our display. This, as Mike puts it, is fine when you are not rendering at full screen, but because you will clip over the edges on full screen, completely ruins the experience on a device like an iPhone.

So, what are we to do? Why, correcting for that inaccuracy seems like a good idea. That's exactly what Mike's code does. Since the final matrix actually creates that negative Z value that we are looking for, it will slowly move the image "away", creating a realistic perspective correction. This is noticed very easily by turning on Mike's debugging mode with a distortion value of ~2500, as in his example, and noticing the arc backwards created by the rotating origin. If you go back and comment out this code, you'll notice the origin follows a straight line across the X axis, resulting in the unrealistic transform we don't want.

So why does this work? Well, it's most easily demonstrated by looking at the application run in debug mode, however what we are really doing is defining a final value that we want Core Animation to have as the transformed Z value, and Core Animation smoothly animates to that value, which ends up rendering a curve as the component is "animated" over time.

If we look at the different values for distortion, we can see the differences in curves. as the ratio 1/DN gets lower and lower, we get a smoother and smoother Z-curve, obviously the point of being too smooth -- to where we don't get a realistic enough curve. To my knowledge, there is no magic ratio for this number. However, I've come up with an interesting little equation, which I think gives a decent recommended Newman Distortion value. I call it the Harris-Lee General Equation for Newman Distortion.

ND = 1 / ((Layer.Height / Layer.Width) / 1000)

This equation is a general equation, meaning it will work on all displays. However, rendering as an art is derived from the aspect ratio of the screen you are rendering on. In addition, we must have a consistent aspect ratio from the layer. With this in mind, we can actually derive a much more precise equation, which can be fine tuned for precise animations.

float layerRatio = 0.0;

if(Layer.Height > Layer.Width)

layerRatio = Layer.Width / Layer.Height;
else if(Layer.Height <= Layer.Width)

layerRatio = Layer.Height / Layer.Width

float maxScreen = 0.0;

if(Screen.Height > Screen.Width)

maxScreen = Screen.Height;
if(Screen.Width > Screen.Height)

maxScreen = Screen.Width;

ND = 1 / (layerRatio / maxScreen);

Let's just plug in some values, based on my own display resolution (1440x900), and the size of the test image (300x400).

ND = 1 / (0.75 / 1440)

ND ~= 2000;

You'll notice this value is very close (relatively speaking) to the magical 2500 number that Mr. Lee came up with. Upon close inspection it gives a pretty smooth curve, and is mathematically derivable. Disclaimer: I have no idea if this is right, but I suspect it works.

@conclusion

Hopefully, despite being long winded, I've shed some light on what exactly is going on. I'd like to thank Mike Lee, Lucas Newman, and Wil Shipley for pushing the envelope of what's possible with Core Animation. Apple for creating Core Animation. Jens Alfke, for inspiring me to become a Mac programmer, and finally my Computer Graphics professors for making me cram all this stuff into my head before they let me graduate in December.

Be back soon!

Edit: Updated with better matrices for posterity and non-embarrassment.

Welcome to 2008.

Hey everyone.

Welcome to the overhaul and relaunch of my blog. One of my New Year's Resolutions was to completely redesign and restructure my blog, and to actually start using it. So, here it is! Over the next few days, I'm going to fill out the content. The look of the blog is based on the old look, and of course some influences from my favorite blogs. I tried to keep it as simple as possible, and I think it came out pretty well. Undoubtedly, I'll be tweaking some of the design here and there, but the overall idea is there.

I hope everyone has a great year!