TL;DR version: This class will let you tile an image in a Metro-style XAML app. Use an image that’s at least 128×128 for best memory efficiency

Textures can make your application beautiful. Here’s an example from http://subtlepatterns.com, which is full of classy textures:

A nice tile texture

These textures can make great backgrounds, but because the texture is usually smaller than your application (especially tiny textures like  ), you need to repeat (tile) the image vertically and horizontally. Images that “match up” on opposite sides are ideal. All the images on  http://subtlepatterns.com, http://bgrepeat.com and http://www.repeatxy.com are tileable.

So how do you program your application to repeat this image across a surface? In HTML, you can use the css style “background-repeat: repeat” to tile an image across your webpage. In WPF, you can set up the TileBrush properties on an ImageBrush to tile an image across your application. But in Silverlight, Silverlight for Windows Phone, or Metro style XAML applications, you’re out of luck.

Fake it

The easiest solution is to use Photoshop (or cheaper equivalent) to create a huge image that you can set as a background. Just use the pattern tool to tile your texture onto an image that’s bigger than your application’s surface will ever be. The question is: can you guarantee a maximum size? With Metro style XAML applications,  there is no maximum resolution. The other problem is that these massive image files tend to use up a LOT of memory. In my case, it was so much memory that I was likely to fail Microsoft’s Win8 certification.

Make it

There was no way I was going to convert my application into a JavaScript & HTML app, so I set out to create a control that would look just like a WPF tiled brush. The easiest way to do this is to manually arrange a set of images in a control. I’m very familiar with WPF, and I just knew there’d be some weird inconsistencies in the new WinRT APIs that made this harder than it should be, so I decided to spike this in WPF first. I inherited from Canvas, gave it an ImageSource property, and slapped my code into the OnRenderSizeChanged method. It worked perfectly, here’s the code:

    public class TileCanvas : Canvas
    {
        public static readonly DependencyProperty ImageSourceProperty = DependencyProperty.Register("ImageSource", typeof(ImageSource), typeof(TileCanvas), new UIPropertyMetadata(null, OnImageSourceChanged));

        private static void OnImageSourceChanged(DependencyObject o, DependencyPropertyChangedEventArgs args)
        {
            ((TileCanvas)o).Rebuild();
        }

        public ImageSource ImageSource
        {
            get { return (ImageSource)GetValue(ImageSourceProperty); }
            set { SetValue(ImageSourceProperty, value); }
        }

        protected override void OnRenderSizeChanged(SizeChangedInfo sizeInfo)
        {
            base.OnRenderSizeChanged(sizeInfo);
            Rebuild();
        }

        private void Rebuild()
        {
            if(ImageSource == null)
            {
                return;
            }

            var size = RenderSize;
            Children.Clear();
            var width = (int)ImageSource.Width;
            var height = (int)ImageSource.Height;
            for (int x = 0; x < size.Width; x += width)
            {
                for (int y = 0; y < size.Height; y += height)
                {
                    var image = new Image { Source = ImageSource };
                    Canvas.SetLeft(image, x);
                    Canvas.SetTop(image, y);
                    Children.Add(image);
                }
            }
            Clip = new RectangleGeometry(new Rect(size));
        }
    }

I broke a convention

If I was a WPF Purist I would have never extended a Panel class in order to provide a visual control. I’d have built a templated control (Inheriting from Control), and declared the canvas as a template part, and provided a default template that just contained that canvas in my Generic.xaml file. But my whole aim was to keep memory usage low, and in WPF every visual costs you memory, so I decided to pre-optimise. It’s also simpler this was as I only have to show you one file .

Optimising Memory

A tilebrush in WPF on a 1000×800 surface will happily repeat a 4 pixel image for you, thousands of times (200,000 to be exact), without breaking a sweat. However, with my TileCanvas, we’re creating an Image visual every time we want to repeat the tile, so you don’t want an ImageSource that’s too small. You have to find a happy balance between a huge image (which uses up a lot of memory by itself) and a lot of small images (where you don’t keep paying for the image data, but you do pay for the visual tree explosion). I have found that by repeating your pattern, Photoshop style, onto an image that’s a sized with a nice round number like 128×128 pixels is a good compromise. This applies to the WPF spike as well as the following Metro solution.

Make it – Metro Style

If you want to build a Metro Style application, you need to program against the WinRT API. This provides .NET developers with new challenges. Microsoft say that WinRT allows .NET developers to use their existing skills, which is fair. What they don’t mention is that you’re going to need a lot of new knowedge. WinRT is like a parallel universe – a lot of the things you expect to find are there, but they are a bit different, or they’re in a different place. A lot of operations are now done asyncronously, which should be make apps snappier. Truly a “parallel” universe (sorry).

When I tried to port my WPF TileCanvas over to use the WinRT version of XAML controls, I ran into two differences that changed the way I had to do things:

• There’s no longer a RenderSizeChanged method – after a bit of experimenting, I decided on the LayoutUpdated event (although adding images causes this event to be raised, so I had to track the old size in order to avoid stack overflow)
• ImageSources now start with a width and height of 0. It’s not until the ImageOpened event is raised that you can find out the width and height of an image. And you don’t get an ImageOpened event until your image is loaded into the Visual Tree. To get around this chicken-and-egg situation, I add a single image to the canvas, and then once it’s opened and I have the width & height I do a proper layout of the whole screen. I also attach to the ImageFailed event to help you debug, and clean up my event subscriptions once they’ve fired.

Here is my working Metro-style TileCanvas:

    public class TileCanvas : Canvas
    {
        public static readonly DependencyProperty ImageSourceProperty = DependencyProperty.Register("ImageSource", typeof(ImageSource), typeof(TileCanvas), new PropertyMetadata(null, ImageSourceChanged));

        private Size lastActualSize;

        public TileCanvas()
        {
            LayoutUpdated += OnLayoutUpdated;
        }

        public ImageSource ImageSource
        {
            get { return (ImageSource)GetValue(ImageSourceProperty); }
            set { SetValue(ImageSourceProperty, value); }
        }

        private void OnLayoutUpdated(object sender, object o)
        {
            var newSize = new Size(ActualWidth, ActualHeight);
            if (lastActualSize != newSize)
            {
                lastActualSize = newSize;
                Rebuild();
            }
        }

        private static void ImageSourceChanged(DependencyObject o, DependencyPropertyChangedEventArgs args)
        {
            TileCanvas self = (TileCanvas)o;
            var src = self.ImageSource;
            if (src != null)
            {
                var image = new Image { Source = src };
                image.ImageOpened += self.ImageOnImageOpened;
                image.ImageFailed += self.ImageOnImageFailed;

                //add it to the visual tree to kick off ImageOpened
                self.Children.Add(image);
            }
        }

        private void ImageOnImageFailed(object sender, ExceptionRoutedEventArgs exceptionRoutedEventArgs)
        {
            var image = (Image)sender;
            image.ImageOpened -= ImageOnImageOpened;
            image.ImageFailed -= ImageOnImageFailed;
            Children.Add(new TextBlock { Text = exceptionRoutedEventArgs.ErrorMessage, Foreground = new SolidColorBrush(Colors.Red) });
        }

        private void ImageOnImageOpened(object sender, RoutedEventArgs routedEventArgs)
        {
            var image = (Image) sender;
            image.ImageOpened -= ImageOnImageOpened;
            image.ImageFailed -= ImageOnImageFailed;
            Rebuild();
        }

        private void Rebuild()
        {
            var bmp = ImageSource as BitmapSource;
            if (bmp == null)
            {
                return;
            }

            var width = bmp.PixelWidth;
            var height = bmp.PixelHeight;

            if(width == 0 || height == 0)
            {
                return;
            }

            Children.Clear();
            for (int x = 0; x < ActualWidth; x += width)
            {
                for (int y = 0; y < ActualHeight; y += height)
                {
                    var image = new Image { Source = ImageSource };
                    Canvas.SetLeft(image, x);
                    Canvas.SetTop(image, y);
                    Children.Add(image);
                }
            }
            Clip = new RectangleGeometry { Rect = new Rect(0, 0, ActualWidth, ActualHeight) };
        }
    }

Almost perfect?

One thing that I would add in future would be to not throw away the entire canvas of images every time it was built. It would be better to determine just how many images need to be added and removed. At the moment, this isn’t a big issue because metro apps are always fullscreen so they don’t change size unless you snap/rotate them.

Shameless plug

I needed this class because I wanted a background texture in my new Windows 8 game, Chromazone. It’s just been accepted my Microsoft to the store, check it out: http://apps.microsoft.com/webpdp/en-US/app/chromazone/fe3aea27-d44f-43e0-8662-1c45178e4dec