Your phone can turn into a robot [LayoutTransformer works great on the Windows Phone platform]

This blog has moved to a new location and comments have been disabled.

All old posts, new posts, and comments can be found on The blog of

See you there!

Comments (19)
  1. mmm very nice David. Great work. I expect lots of interest in this in a couple of months. 🙂



  2. By convention established by architects, engineers and manufacturers who long ago established a standard for rotating text the orientation of rotated text which is rotated to the "six o'clock" position is best read in the orientation that the text "These words" does as depicted in the image above.

    Despite what the book publishers do and what artsy-fartsy designers who think breaking with the Cartesian convention equates with good design, the more experienced and serious design professionals that adopted the convention (I use whenever possible to do so) learned doing so in the manner we have adopted at six o'clock reduces mistakes when trying to read rotated text.

    It was learned that text oriented as your final result shows often causes some type of temporary visual dyslexia. This is serious business when the results of your work can cause somebody to make a reading mistake that can cause the loss of one's safety, health or welfare.

  3. David Anson says:

    Clinton Gallagher,

    Thanks for the lesson! As you can tell, I'm just matching the way books are done because my sample was supposed to be a virtual bookshelf. But if I ever get into publishing, I'll consider breaking with tradition! 🙂

  4. sanjiv kumar (INDIA) says:


    It is hard to build a robot.

    I think that, may be i can build a robot when i will be self dependent & graduated.


    We should take respect to the scientists of the EARTH.


  5. David Anson says:

    sanjiv kumar (INDIA),

    Yes, thank you, I certainly wasn't trying to disrespect scientists. 🙂

  6. gyurisc says:

    I followed the instruction of the article and I have a problem when using an Image. I posted a question on stackoverflow describing my problem. Would it be possible to have a look at it, please?…/parts-of-image-missing-when-using-scaletransform-with-layouttransformer-and-scrol

  7. David Anson says:


    From the description there, I'm not sure what's going on. You might try the same scenario on Silverlight 4 (where LayoutTransformer is part of the Silverlight 4 Toolkit) to see if it happens there, too. If not, it could be a Windows Phone-specific issue (possibly with ScrollViewer). You might also share a picture (or small demonstration application) of what's happening because that might help others determine what's going on.

    Hope this helps!

  8. gyurisc says:

    I tried with the Silverlight toolkit and it did not happen there, so this seems to be windows phone specific. I will share a sample project for demonstration purposes.

  9. gyurisc says:

    my test project can be found here. All you need to do is just to start zoom in couple of times and then scroll to the bottom right of the image, you will see the missing image and the black area. This is where you can download the project from…/

  10. David Anson says:


    Thanks for the great demonstration! This problem turns out to be due to a limitation of Silverlight on Windows Phone 7 – that UI elements larger than 2048×2048 get clipped to that size when being displayed. Here's a link to some more information about the problem:…/bitmapimage-size-restrictions-in-silverlight

    In your example, the test image is 1201×1401 and I first notice clipping after 3 "Zoom In"s – which corresponds to a zoom factor of 1.9x – which translates to an effective image size of 2282×2662 – which exceeds the limits in both directions. Doing the math to compute the amount this exceeds 2048 gives 234 in the horizontal direction and 614 in the vertical. Now keep those numbers in mind and scroll all the way to the bottom-right of the ScrollViewer on your phone's 480×800 screen. Note that the amount of horizontal black space is approximately half the screen width (i.e., ~240px) and the vertical black space is about three quarters of the screen height (i.e., 600px) – because these estimates match up so closely with the overages we've just computed, I'm fairly confident you're running into *this* problem.

    Unfortunately, it's a platform limitation (which you already confirmed by running your scenario successfully on desktop Silverlight) and therefore not something I can directly fix in LayoutTransformer. Fortunately, there are some workarounds which are discussed in the thread/link above.

    Sorry for the trouble – I hope this helps!

  11. gyurisc says:

    Thanks for the explanation. I will try this and will post it back!

  12. chustar says:

    Since WP still doesn't support layout panels, would you consider putting this up on nuget?

  13. David Anson says:


    I didn't do that originally because it seemed like a lot of overhead for a single class. If I had an environment handy where I could build and test it right now, I'd do so – but I reinstalled most of my computers recently and don't. 😐 Sorry about that!

  14. chustar says:

    Thanks though!

  15. Jesse says:

    I have a storyboard animation which animates a ScaleTransform (on windows phone 8). I used the LayoutTransformer so the rest of the visual tree resizes with it. Am I right when I say this turns it into a dependent animation instead of an independent? Which means it won't use the composition thread and it all runs on the UI thread. Which makes the animation run at a very low framerate.

  16. David Anson says:


    Sorry, it's been long enough since I dealt with this that I'm not sure about the answer to your question. That said, I don't *think* that the amount of content changes an animation's type and I *think* that ScaleTransform is an independent transform. I looked briefly online and didn't find any good references on the topic, so I'd say that measuring performance on a real device is probably your best option. Please do bear in mind that changes to the *size* of a LayoutTransformer cause it to re-layout and that's definitely not a render thread operation. Depending on how your scenario is hooked up, this could be an issue.

    Hope this helps!

  17. Marcel says:

    I don't see LayoutTransformer.dll anywhere in the Windows Phone Toolkit since it split off from the Silverlight Toolkit.  Is the best option to download the Silverlight Toolkit and copy the dll into the project from there?

  18. David Anson says:

    It looks like they didn't include LayoutTransformer in the Windows Phone Toolkit. I'm not sure why, but it has always been a single CS file, so you can add it directly to your project or incorporate it into a custom build of the Toolkit if you wish. Sorry for the inconvenience!

Comments are closed.

Skip to main content