Pixels and Bit Twiddling, pt 1

I was discussing bit manipulation with somebody and it reminded me of one of my single favorite pixel munging routines. I've purposely omitted the NAME of the function - but its pretty cool ("One from the book", as Paul Erdos might say). And this one was really originally written (meaning he showed me the trick first) by the prime "PixelBoy" himself, Ben Weiss.

inline uint32 FUNCTION_NAME_OMITTED (uint32 a, uint32 b, uint32 mask=0x01010100)
{
uint32 s = (a + b);
uint32 c = (a ^ b ^ s) & mask;
return (s-c) (c-(c>>8));
}

Any guesses as to what it does?

I'll give you a hint: its a 32 bit pixel operation, but doesn't preserve alpha in this case (if only you could access the carry bit from plain old C ... ).... Just decoding what this did taught me a LOT about graphics coding, back in the day.

The OCP - what is it?

The Open Client Platform (henceforth OCP) is the underlying set of principles, processes, and code that drive our current (and upcoming) generation of desktop software.

We kicked off the design of the OCP at one of AOL's first internal developer's conferences in the Spring of '04, and have been accretively driving our way to some interesting applications, opportunities and possibilities. (I'll talk a little more specifically about the goals, vision, and execution of the OCP at some point in the future)

The OCP is built on the foundation of a few "pillars" - technology components (Services) that, for lack of a better word, bound the platform, and in doing so, define it. They are:

1) Execution Engine (EE). The EE is the runtime layer for the OCP. It provides core services (lowercase "s") like discovery, messaging, etc. - its basically our object and Service interop layer, and so is pretty much a thin wrapper on COM(on Windows; on the Mac it sits right on DO/Objective-C). From a design perspective, we tried to limit the specific features we provided (and hence design patterns we would allow - the old 80/20 rule) because we thought, "it is good", but more than that minimalism was a key driver in ALL of our APIs at a platform level. We also wanted both abstraction from, but compatibility with, the underlying OS and its services - and the EE provides just that: its the skeleton of our framework of thought.

2) Common Local Storage (CLS). I'm a big believer that, as a practical matter, your data model drives your design. With CLS, we sought to provide a simple common way for Services to store stuff. The core of CLS is SQLite (which we helped move from 2.x to 3 in the course of using and abusing), but more than just that there's a data abstraction layer that's important which CLS encapsulates and provides. Two simple examples? Identity-scoped data (one subclass of data domain-ing generally) and transparent sync. Sync is the data model of the future (you don't want your data just anywhere, you want it everywhere - more on this in the future, too), and we're touching on the beginnings of that in CLS.

3) Boxely. Originally called "UI&Presentation Layer" this was probably the most controversial of the services we established as an early part of the OCP. There were a lot of ways this could have gone down - from extending FDO (the base of the existing, at the time, AOL host and client tech), to Flash/MXML, to XML over Win32, maybe XUL, to even XAML, but in the end, it was Boxely that became the path. Boxely is an entirely home grown custom UI kit for desktop applications. And custom UI is hard - the big question is always going to be "Why?", but I believe that desktop applications, especially consumer apps, are about the user experience: their UI.

So when people ask "Why?", well, "Because it matters."

There are few others that are probably "up there": Noser, SUDS, etc. but these I view these as the "big 3". You'll note they roughly correspond to Runtime, Storage, and Presentation.

I'll discuss Boxely in depth next.

Pixar, Firefox and AOL Explorer

So I meant this to be more timely, but whattya gonna do?

This is really more a story about software developers and our mindsets (good and bad) than it is about Pixar, per se, but as I said, its almost timely :)

A few years ago, a few friends and I were at SIGGRAPH, and we attended the Ray Tracing Roundup (yes, yes, I know, we are tres cool - you know you wanna hang with us). This was still in the early(ish) days of 3D HW acceleration; it was around and games were doing a lot with it, but it was still new and a lot of the discussion was about software v. hardware - scanline renderers v. raytracers, etc.

The folks from Pixar, of course, were the dudes - they did a lot of pontificating, mostly on point, but definitely were the center of attention. At some point someone (else) argued that software stuff was more flexible, allowed for more differentiation, more tricks and specialization etc. (These days, of course, its all software - just a question of which processor in your PC is best for the task at hand ;P)

The Pixar guys went into a big long diatribe about physical correctness, the importance of research and specs and physics and light - blah blah, and - in support - some guy from ART started describing how they had followed the Pixar spec, had implemented a raytracer in HW, that procedural graphics could be HW accelerated, etc - kind of a Turing complete argument for 3d.

Poor guy.

If there's one thing engineers probably dislike more than being disagreed with, its being agreed with :)

So one of the Pixar guys - no names required - truthfully, we've all been there; stick with me - you'll see... so one of the Pixar guys then proceeds to just dismember the guy. They've learned so much over the last 10 years, graphics has come so far, the spec is stale, what were they thinking (kinda just generally missing the point - which was NOT about specs IMHO but programmability - but that's ALSO neither here nor there).

This continued for a long enough period that I still recall the increasing embarrasment we all felt for the ART developer...

And then, from the back of the room, a somewhat quiet, tad bit nebbishy guy stands up (who turns out to be Dan Ward - sorry Dan :)) - and says the following:

"If I understand correctly, what you're saying is that over time things change and progress - we all learn a lot and grow, but the one thing that stayed constant is that you're still right."

HAH - point. The room exploded - it was fun....

That's kinda what all the Firefox arguments remind me of... yes, its nice to have access to the code; yes its a nicer engine in a lot of ways, but the question is: is it really better in ways that still matter?

I'll dive into the questions (security especially) in the near future, because I know what a lot of my tech brethren think, but my main point was this - oy and yeesh - relax with the rhetoric already :)

All that aside - I am glad it exists, and that we (royal AOL we here) helped pay for it; keeps everybody else honest.

Google and China

And so it begins... welcome to the market pressures of being a public company.
(what, they NEED more money?)
From slashdot:

Re:Bold Statement(Score:5, Insightful)
by Ph33r th3 g(O)at (592622) on Wednesday January 25, @12:27AM (#14554782)
Yes, they do have a choice. Rather than assist the PRC in violating human rights, they could decline to do business in China. There's all the talk here about how they faced down Bellsouth--don't you think they maybe have a little market power in China, too? Well, not now--they caved to the almighty yuan. I'm sure the dead Christians and the Tianmen Square students crushed under the treads of the people's tanks are thankful censored Google is available thanks to the sweetheart deal with the Chinese Communists. [ Reply to This Parent ]

Re:Bold Statement(Score:5, Funny)
by martinX (672498) on Wednesday January 25, @12:38AM (#14554869)
what dead christians? what crushed students? i searched www.google.cn and couldn't find any of this?

Pixar and Disney

Wow. Big news. This is a great move for both companies, IMHO. And good timing. The concern of course would be that Pixar has really had a great run as independent studio delivering blockbusters, and that being part of the Mouse House will, well, blunt their energy and fire.

I don't think it'll happen- I think they get off on making great movies, not anything else. However, I predict that "Cars" (Pixar's latest upcoming) will NOT do as well as some of its previous flicks (though it'll do ok by anyone else's standards). That'll prompt folks to doubt the value, but over time, Pixar will deliver, and it'll keep Disney relevant and healthy in the family picture biz (with the all the ancillary benefits and opportunities that implies).

More interesting is Steve Jobs as a media mogul. Its been building for a while - this makes it official.

AOL Explorer 1.1 and 1.2

Updated: Finally wrote that Internet Explorer vs. Firefox/Gecko post.

So we built a browser (skin) last year. Its based on IE, and we shipped the first version in the summer, which for arcane, not really important reasons, was version 1.1. As a part of AIM Triton and the AOL Suite, we also just shipped version 1.2 in December.

I'll explain in some detail in a future post why we chose IE - though we've generally recieved pretty positive reviews for an AOL browser since it GM'ed in July, that we chose to bet on IE has been probably the only consistent and nagging ding. It bears some exploration (no pun intended :))

Interestingly, version 1.1 was built in HTML. That is, the chrome itself was actually just DHTML content (no, not AJAX - DHTML; there is a difference you know). In version 1.2, we rebuilt the whole thing with Boxely, which I'll also be discussing in some depth. This made it a lot easier to do some fun stuff. Nothing you haven't seen before (in principle) but... try it.

We've had, over the last year, quite a bit of mileage in building desktop applications with markup and script. We've got probably a good 10million+ uniques running desktop apps built this way, and there have been some pros and cons - though ultimately, it IS how apps will be built.

Someday.

In the meantime, I think we're among the bold few attempting to use script for Programming in the Large, as they say, at least for desktop apps. There are pros, and there are cons. More on that soon.

This blog.

I've been at AOL for about 2 years now (yoinks, it goes fast). I've been working on revamping our applications and the infrastructure that support them for, well, pretty much that whole time. Its been slower going than I'd like, but we've reached at least the end of the beginning. That is to say, there's a LOT more to do still...

I hope that some of that journey is of interest, so expect to hear more about the what's, why's and how's. This is intended to be an "industry" blog - that is, lots of stuff about work and the industry in general.

To provide some context to future posts, my group shipped (I've been running the desktop applications group), over the last 6 months: AIM Triton 1.0 (www.aim.com), AOL Explorer 1.1 and 1.2 (some technology differences worth discussion there), Internet Access Controls 2.0 (parental web controls for Broadband), Computer Checkup 4.0 (, AOL Connectivity Service 4.0 (our connectivity engine), the AOL Suite 1.0 Preview, AOL AntiSpyware 2.0, and the AOL Security Center 1.0, among very many other things.

Scarily (other than ACS 4.0) its been basically all new code, on an all new foundation that we call the Open Client Platform (OCP). Despite various version numbers on the apps themselves, they're all basically 1.0 applications. By that I mean they share almost no code with previous versions (in any really recognizable form). Not sure its the path I would have, left to my own devices, chosen, but there you have it. As I tell my teams all the time: may not have been smart, but it is impressive. Here I'll share some of the gore :)

Welcome.

Updated (3): Joined Comast as SVP and Chief Software Architect.

Updated (2): Departing AOL. Details here.

Updated (1): New(-ish) job - Included in my group at AOL are: Desktop Client infrastructure (OCP), Host infrastructure (SOA), Instant Messaging and Realtime communications (AIM), Publishing systems, Search development, Mail Host infrastructure, and the new Billing and Business Infrastructure.

So I have a blog. (AKA testing.. 1... 2.... 3).

I'm Sree Kotay.

I work(ed) at AOL developing software (design, UI, engineering, qualifying, shipping) as a Senior VP in the Technology group.

Before that, I was at Viewpoint as CTO, building the Viewpoint Media Player - original specs, code, vision, etc.

Before that, I was Director of R&D at Metacreations, nee' Metatools, nee' HSC Software. We did some good stuff - folks would be surprised how much that work continues to reverberate even today.

Before that, I was President of a small software company called Intrepid Systems. Mostly pre-press and high-end graphics workflow software.

Software I've worked on, AKA run my code/designs in some meaningful way even now (mostly graphics code - hence the blog title; trying to earn some cred'):

- AOL stuff (more discussion of that shortly)
- Meta-stuff (Bryce, Carrara, Poser, et al.)
- Mapquest (Yep - they render maps with my code, though that's about it)
- Viewpoint (Viewpoint Media Player, SWF Player, Tools, etc.)