I’m continuing work on my mac project, which involves a scalable document that can be embedded in an NSScrollView. I recently wanted to add orientation to the set of valid transformations. While I’m sure there are more generic solutions that involve setting a composite affine transformation on the underlying CALayer, I wanted something that I could implement in an hour or so. I ran into some issues that I thought I’d write about in hopes of saving other people some time.

When coding against the SDK for OS X Lion, NSView has a setFrameCenterRotation: selector, which is very convenient for rotating about the center of the view. If you need to run against older versions of OS X, you can use a combination of setFrameOrigin: and setFrameRotation: to accomplish the same thing. These rotations don’t affect the internal coordinate system of the NSView, but change its frame in the superview – also very convenient when it comes to performing layout in the rotated view.

I experimented with these for my document view’s transformations and found some quirks. Firstly, I tried to simply rotate the NSScrollView’s documentView. From my previous post, this is the HostView object. That didn’t go quite as well as I had hoped: the rotation occurred around the incorrect locus, and the scroll view got very confused about positioning. When I performed the rotation, the document would jump to an odd place, and then when I moved the scroll bars, the document would jump back to the origin.

After that, I attempted to rotate the _docView inside the HostView object. Success! At least, initial success: while the rotation occurred and the document stayed stable inside the scroll view, the dimensions of the HostView object stayed the same and the _docView was positioned incorrectly. I found that the NSViewFrameDidChangeNotification was still being raised. When I analyzed the newly calculated frame for the HostView, I found the width and height were the same as the original, when it should have been changed.

Changing the code in updateFrame: to detect the _docView in landscape orientation and transforming the frame appropriately makes the scroll view recalculate its scroll extents correctly. There’s still the problem of the incorrectly positioned document. I’m not sure why Cocoa does this, but when calculating the frame for a rotation, the view would consistently get shifted by a size proportional to the size of the view. I had to manually adjust the frame after the rotation had adjusted it.

After all is said and done, the new code looks like this.

This article reminded me that I wanted to write about 3-D movies.

Many people have written about how 3-D won't work due to physiological
issues with eye strain and wearing glasses for extended periods of
time. While these issues are real, I have faith that technology will
get to the point where these issues are mitigated if not eliminated.

Everyone knows that movies are entertainment, and as such, an
unnecessary good. The market has already priced out this good:
entertain me for about 2 hours and I will pay $10 for that
entertainment. Theaters have thus far priced 3-D movies as a marginal
good: 3-D is better and thus should be higher value. The only problem
is, it isn't (or at best, the margin is short lived).

I wonder if "talkies" demanded a higher ticket price when they were introduced?

Once 3-D movies cost the same as a regular projection, they will
simply become the norm at theaters because all the other reasons to go
to the theater (timed releases, big screen, popcorn?) will have
eroded. The theater is already becoming a throw-away entertainment
activity, and 3-D will be the only thing keeping them alive, until the
next technology comes along. Personal surround sound, anyone?

~s

In November, an article indicated that Intel was ready to open up its fabs to other chip designers.

AMD famously spun off their foundry capabilities into The Foundry Group, basically admitting that it was too expensive to maintain investments in fabrication while only manufacturing their own chips. The move also let AMD leverage competitive investments at other fabricators such as TSMC (Taiwanese Semiconductor Manufacturing Company). ARM paved the way for this kind of thinking many years ago, being one of the first fabless semiconductor companies. NVIDIA decided to go down this route as well. It’s just too expensive to maintain fabs yourself unless your volumes are absolutely massive.

There are some great reasons to have a fab, though. When making a chip, there are many factors that go into its profitability. Among them are size, power, performance, and cost of materials. Owning a fab and the process used therein enables you to optimize each of them. Intel has long held the performance crown by way of being vertically integrated, from architecture & design, down to the process used to lay transistors.

As transistors have gotten smaller, it has taken more and more ingenuity to cram more computing power into the same area. It takes a long time to research the materials science involved, and Intel has lots of proprietary technology in this area. So much that the rest of the industry feels the need to band together to compete.

When a contract semiconductor manufacturer allows others to use its process for making chips, it has to disclose lots of details to the chip designers. This is because chip designers need to simulate their chips on the process to understand nano-scale effects such as wire capacitance and impedance before sending the final designs to be manufactured.

By allowing others to build chips on their process, Intel is opening up a lot more than just a revenue stream. Of course, they realize this, and it is unlikely that they will end up making AMD’s chips. However, rumors this past week had Intel in a position to manufacture Apple’s A4 and A5. However, it is unclear to me what Intel has to gain from making ARM chips better than the other guy.

There are lots of wins to be had for Apple to use Intel’s process technology on these chips. The A5 is massive and could benefit from smaller, tighter process technologies with higher yields. With the relationship between Apple and Samsung souring, the move makes sense.

However, I think there is another move that could be even more interesting for Apple to make: buy its own fab. Apple always strives to be vertically integrated, and this would be one more step along the way to not relying on anyone else. If Apple could then build an innovative portfolio of process technologies, it would hold a yet larger lead on competitors.