In case you missed it, there was a giant 6 metre wide plasma wall at TechEd that streamed tweets (from Twitter obviously) and various images from Flickr. We took the following feeds:
- Anything with the #auteched hashtag in it appeared on the tweet slide;
- Anything with #news and #auteched hashtags in it from the user @auteched (the ‘official’ news feed for the event) was used for the blue news slide;
- Anything from the TechEd Australia Flickr set was used for the photo sets.
The app itself was written using .NET 4 + WPF and Visual Studio 2010.
The PC that ran the display (“riceputer”, my blingy gaming rig, named after four-banger rice cars):
- Intel Core i7 920 @ 2.67GHz
- Radeon HD5850 (1GB RAM)
- 3GB of triple channel RAM
The display formed a centre-piece for the community in the expo hall. It was received really well by the delegates and hopefully this will become a permanent fixture at tech•eds of the future. The expo wall was used as backing on the main stage and there were a heap of beanbags and comfy couches around in front of it – the whole area had a really nice community feel. We saw heaps of people sitting around and tweeting to see if their tweets would pop up on the display (come on guys, as if we’d smoke-and-mirrors you – you’re all too smart for that :))
Technical Direction Company (the audio visual supplier to the event) provided the display and the necessary matrix hardware. We provided a 1080p DVI feed (1920 x 1080) and they used a device called a Sypder (from Vista Systems) to split the top 729 pixels of that feed across all of the plasmas. You can see the initial calibration of the display in this video (sorry for the end bit, Patrick :)).[youtube lmmhSyfi-eA]
In terms of application development (and it will be no surprise to any of the developers reading this): WPF is a thirsty beast. The application had to run 12 hours a day without a glitch or leak and this proved to be very difficult to achieve with WPF.
The individual character animations on the tweet screen were achieved by:
- Downloading the tweets in a background thread and scrubbing that against a profanity filter;
- Using GetGlyphTypeface() on the TextBlock object to read the metrics for the individual characters in the tweet (see this http://i.msdn.microsoft.com/dynimg/IC26720.png).
- Create a separate TextBlock control for each of the characters in the tweet. We did this while honouring all of the kerning etc in the original font glyphs;
- Animate each of the characters individually to achieve arbitrary layout effects and animations.
In retrospect, this was a LOT of work that probably was lost on people watching the display. If we had our time over we might have just stuck with animating an individual TextBlock or Canvas and transitioning the tweets in in one hit (as was the case on the blue News @ TechEd slide).
We found that using storyboard based animations was very problematic. Each time the tweets appear we bring in four at a time, in four sets for a total of 16 tweets meaning a worst case scenario of ~2500 individual items in the storyboard. We tried a lot of different approaches to interacting with the WPF storyboards but in all cases we found that there were subtle leaks, even for items that were well out of scope. Over time (and remember we’re running this all day and night) memory usage would creep up.
In the end, we resolved to ditch storyboards altogether and manually created the WPF animations and queued them up ourselves. Once we did this, the memory leakage issues disappeared and the app would sit on a steady 111 meg of RAM usage indefinitely.
We found that the static storyboarding in WPF was excellent for prototyping (i.e. just writing up XAML by hand) but as soon as you start modifying those in code you’re in for a world of pain. That isn’t really an isolated experience as far as we can tell – check out the memory usage on Blu, MetroTwit, etc.
For next year, it would be great to do this again using the new Twitter streaming APIs and XNA.