Random Thoughts

Tech, words and musings from an Englishman in Seattle

Testing On The Toilet

Since I joined Google, I've been incredibly impressed by the focus on testing. You've probably heard that you can't escape even when you're in the bathroom - the test team post flyers in the stalls and in front of the urinals with useful testing hints.

Testing on the Toilet

Well now you get to see them too! The Engineering Test Team have opened them up on their new public blog.

We're unveiling the public release of “Testing on the Toilet”: one of Google's little secrets that has helped us to inspire our developers to write well-tested code. We write flyers about everything from dependency injection to code coverage, and then regularly plaster the bathrooms all over Google with each episode, almost 500 stalls worldwide. We've received a lot of feedback about it. Some favorable (“This is great because I'm always forgetting to bring my copy of Linux Nerd 2000 to the bathroom!”) and some not (“I'm trying to use the bathroom, can you folks please just LEAVE ME ALONE?”). Even the Washington Post noticed.


IE7 Annoyance

If you visit this blog with IE7, you'll get a topbar thing that tells you that the site wants to run the “Windows Media Player Extender” ActiveX control.

Since I did no such thing, I have no idea what is causing this. Of course I could voodoo debug the site and disable everything one by one until the culprit reveals itself, but I'd rather have you, dear readers (especially you webdevs out there) tell me what the problem is.

Prize for the winner. Well, maybe not, but you'll get my thanks anyhow :-)

Tags: , , , .

Audio Acceleration on the GPU?

This post, ATI eyes audio acceleration on the GPU, had me remenicing about the early days of Direct3D again.

What most people don't realize is that in the early days on Direct3D many of the 3D accelerators (or sometimes “decelerators”1) where in fact very general purpose DSPs. At that point in time (mid-1995) many of the hardware guys were very surprised at the rapid mindshare growth of consumer 3D hardware. We're talking people like Evans and Sutherland, SGI, etc…

Brief interlude.

Regarding Direct3D and the following OpenGL v. Direct3D wars, one point I feel is worth making is that if it were not for Direct3D, we would not have the gaming platforms that we have today.

In 1995, 3D was stalled, noone was innovating and OpenGL was stagnant. It was only after the release of Direct3D that OpenGL started to make any headway.

In fact, at lunch during the hardware guys' day at Aftermath event, we put a pre-release PS1 on the main video screen running Tekken in demo mode. You could see the palpable fear in most of the hardware guys' faces. “What is that?” “That's not realtime.” These guys, with very few exceptions, were missing the boat.

End of interlude, now where was I?

Many hardware startups in the Valley at that time were putting together DSP based ISA (or even the new PCI) boards to offload modem, audio and other functionality from the overwhelmed CPU.

These guys recognized a good thing when they saw it and decided that they could add 3D graphics too. It's all just vector math isn't it?

The Chromatic Mpact part was a case in point. It was a modem, an audio card and a 3D accelerator all rolled into one! Step right up! Well, until you tried to run a few thousand triangles per second through it. Mind you, they had some very cool booths at the shows.

None of the parts of this generation performed triangle setup (apart from the 3DFX Voodoo 1) and they all sucked to one degree or another.

But a special place in my heart is taken by the Rendition Veritee 1000.

Rendition was a true entrepreneureal company built by engineers. Those guys were great. They were the only guys to have hardware ready for Comdex 1995 where we (or rather Ty Graham, our hardware evangelist) showed hardware-accelerated Direct3D for the first time.

Servan (one of the founders of RenderMorphics) and I had locked ourselves away in an office on campus after the Aftermath event and we had a week until Comdex. We finished the driver model, an API that could drive it and had the famous2 “tunnel” sample running on it.

But for a driver model we needed a driver and some hardware. Here was where Rendition really stepped up. One of the guys from Rendition came up to Redmond and basically lived with us. He was writing driver code while we were writing the driver model. Talk about bleeding edge.

The prototype, hot off the chip foundry, V1000 was mounted on a red prototype board with a fan glued to it. Unfortunately, when plugged into the bus on the machines we had, the board was upside down and every hour or so the glue would melt and the fan would fall off. Much hilarity ensued. Much pizza was eaten.

At four in the morning on the first day of Comdex, Ty walked into the office, already late for his flight to Vegas, and witnessed tunnel running at lightning frame rates. We packed up the dev machine in a flight case and off he went - by all accounts everyone was awed by this cheap piece of consumer 3D hardware.

I still have that board.

But that's not the point of this narrative.

The point is that the V1000 was a DSP based part that stored it's microcode in it's onboard memory in an address space just below VGA memory.

Which meant that any bug in the driver, especially the clipping code, caused Direct3D to render triangle fragments all over the microcode. It didn't just blue screen. Can you say hard lockup, push the big red reset button?

And here's my other point. Man, was that fun.

[Thanks to Ars Technica for the link.]

1 This term was originally applied to one the first parts out of S3 and I think, ahem, that I coined it… 

OS X Developer Tools

Am I missing something?

Now that CodeWarrior appears to be dead as far as Mac development goes, the only option appears to be Xcode - the free development toolsuite shipped by Apple.

Now, leaving aside the fact that Xcode's UI and workflow appears to have been written by a monkey on acid, it does appear to work fine, with one exception.

The debugger.

Now, gdb is a fine debugger, but it is basically a console based debugger and works fine when used in the environment for which it was designed. I cut my debugging teeth using gdb back in the '80s. In fact, I had to build the remote end of gdb for the Amiga so that I could do some cross-complilation game development.

But that's another story.

Xcode uses gdb as it's debugger, thinly veiling it with some shoddy UI that is constantly getting itself out of sync and generally not working well. Especially when you're working on multi-threaded code.

Now, I'm also a big user of cdb/ntsd on Windows - again, console debuggers. But their usage has a time and a place. Productivity is vastly increased by great visual debugging tools.

This is where Microsoft completely shines. Visual Studio is a great debugger - say what you will about the build tools, language support, etc… but VC is a great debugger for user-mode applications.

This is why Windows is the platform that it is. Microsoft gets it. To get massive developer support, you need great developer tools1. If Apple wants massive platform support from the developers, they've got to improve the Xcode debugger. Like, actually provide one.

As a developer, I don't want to be beating my head up against the wall because of the tools, and unfortunately Xcode is giving me a nice, shiny, bruise on my forehead.

And don't get me started on the Carbon SDK, but I think that's a post for another time…

1 Coincidentally, this is why the Xbox 360 is a far easier platform to develop for than the PS3. 

When SetFocus Doesn't

So we were recently debugging a little problem in Flight Simulator that occurred when we were transferring focus between child windows using SetFocus. The problem was that SetFocus was returning NULL (which, according to the docs is an error condition), but a subsequent call to GetLastError returned 0 (everything is fine and dandy). A call to GetFocus confirmed that the focus hadn't changed.

After much debugging we figured it out. The target window was being hooked via a WH_CBT hook which was returning TRUE in response to a HCBT_SETFOCUS - i.e. the hook was telling the OS not to transfer focus. It would have been nice to have received some sort of useful error like ERROR_HOOK_JUST_MESSED_WITH_YOU.

Lesson learnt. Window hooks can mess with you when you least expect it.

After figuring that out I pinged Raymond Chen about the issue and this is what he had to say:

The reason you don't get a userful error is that the window manager doesn't even know that an error occurred. You called SetFocus. The window manager dispatched it to a hook. The hook returned the code "It's taken care of, no worries," and the window manager says "Okay, well then that's that." With a hook, a program can modify or even replace certain parts of the window manager. Of course, with that power comes great responsibility. If a hook wants to make SetFocus fail then it's the hook's responsibility to set an error code.

© 2001 to present, Steve Lacey.