UI Scaling (UI Zooming) with WPF

WPF enables the application developer to apply arbitrary transforms to every UI element. This can be used to create dynamically scalable/zoomable UIs, enabling the end-user to scale the user interface of the application.

Pulling off a dynamically scalable/zoomable UI is prohibitively difficult (and thus practically impossible) to do in classic Win32 (and by extension – WinForms) and DHTML as well as other popular GUI toolkits such as AWT, Swing, QT, etc. It is, however, remarkably easy to do in WPF. Here’s how:

1.       First, you need to give to the user a way to control the scale factor. A Slider control is the natural choice for that



    ToolTip=Determines the UI scale factor.

    Value=1 Minimum=0.1 Maximum=4




2.       Next, define a LayoutTransform for the FrameworkElement you intend to scale (this is typically the top-level panel that contains all of your UI). The LayoutTransform needs to be a ScaleTransform.


3.       Bind the scale factor of the ScaleTransform to the value of the slider control.

<DockPanel Grid.Column=0Grid.ColumnSpan=2LastChildFill=True>




            ScaleX={Binding ElementName=uiScaleSlider,Path=Value}

            ScaleY={Binding ElementName=uiScaleSlider,Path=Value}






4.       Finally, provide a way for the user to reset the scaling factor back to 1 or 100%. One way to do that is to do that is to define a double-click handler for your Scale control, which resets the scale factor:

public partial class Window1 : System.Windows.Window


    public Window1()



        uiScaleSlider.MouseDoubleClick +=

            new MouseButtonEventHandler(RestoreScalingFactor); 



    void RestoreScalingFactor(object sender, MouseButtonEventArgs args)


        ((Slider)sender).Value = 1.0; 




Here are the results:


Note that because of the use of LayoutTransform, the original layout of the window is preserved. All of elements of the UI are within reach and completely usable regardless of the current scale factor.

Adding mouse wheel support

Several existing WPF applications (e.g. Microsoft Expression Blend) already expose such UI scaling capability. Some use the mouse wheel to control the scale factor.

Here’s one possible strategy of using the mouse-wheel. Let’s assume the following UI contract:


UI meaning

CTRL + Wheel up

Scale up (i.e. zoom in)

CTRL + Wheel down

Scale down (i.e. zoom out)

CTRL + Wheel click

Restore scaling factor to 100%


We just intercept the appropriate events in the OnPreviewMouseWheel and OnPreviewMouseDown methods of the main window as follows:

public partial class Window1 : System.Windows.Window


    public Window1()







    protected override void OnPreviewMouseWheel(MouseWheelEventArgs args)



        if (Keyboard.IsKeyDown(Key.LeftCtrl) ||



            uiScaleSlider.Value += (args.Delta > 0) ? 0.1 : -0.1;




    protected override void OnPreviewMouseDown(MouseButtonEventArgs args)



        if (Keyboard.IsKeyDown(Key.LeftCtrl) ||



            if (args.MiddleButton == MouseButtonState.Pressed)


                RestoreScalingFactor(uiScaleSlider, args);






Comments (18)

  1. WPF enables the application developer to apply arbitrary transforms to every UI element. This can be

  2. rq says:

    Eye, I agree it is easier but watch the cut-off of 100% CPU utilisation be so painfully slow..

    WPF needs performance work people, I don’t know how many times that needs to be said to realise it will fail because it is so pathetic in rendering.

    Go native if you have to achieve it but please do not advocate it is without a major, design fault so far: requiring a CrayT90000

  3. ivom says:


    On my laptop (Inspiron 6000 with 2 GB RAM, 2.13 GHz single-core CPU and a Radeon X300 video card), I cannot get to 100% CPU utilization. The base CPU utilization I start from (when I start the application and leave it be, alongside the other 65 processes I have running on my machine) is about 15%. Vigorous re-scaling of the UI only gets me as high as about 75% CPU utilization. So the CPU utilization in this particular scenario is not that bad (at least on my laptop) given the fact that the layout transforms trigger both re-rendering and recalculation of the layout. The "perceived performance" (which arguably is more important than any measured perf, although there are exceptions) is pretty good too — the UI scaling feature in the attached sample is very usable from that point of view.

    This of course is not to say that there is no perf work ahead of us. Performance is one of the things we take really seriously (we have a dedicated performance team and performance lab, most of the feature teams have specific performance work-items, we have automated performance tests we run daily, etc., etc.) and we are constantly investing in it. We have done a lot of performance work for the upcoming .NET 3.5 release, specifically around rendering, but also to improve cold-start perf, data-binding perf, etc. I will publish details on what’s new in the 3.5 release one of these days.

    The managed-vs-unmanaged call is something that is debated within Microsoft too and is something that unfortunately tends to take religious proportions way too often . Having worked with both managed and unmanaged code, my personal opinion is that  any system of sufficient complexity is bound to face performance challenges. These challenges cannot be overcome by switching from C# to C++/assembly/etc. They can only be overcome by ensuring that performance is an ongoing investment, something that is constantly thought about, measured, etc. at all stages of the development of the product. Incidentally, the same thing applies to other “fundamentals”. There are for example folks who think that unmanaged code is inherently insecure and that using managed code automatically guarantees high levels of security.

    Anyways, I diverge. We know that we have some performance work ahead of us and we are investing there heavily. Thanks for your response and thanks for caring!  It’s great that you guys are “keeping us honest” and challenging us constantly so that we can continuously improve the product. Keep the feedback coming!



  4. Andrew Jones says:

    Thanks. I’m just starting to use WPF for some real world apps and your notes helped me to get a zoomable UI up and running in seconds.

  5. Scaler says:

    I’m having a canvas in a scrollviewer, like the code below. The scaling works brilliantly when zooming in, when zooming out my canvas is getting smaller. I would like my canvas to keep filling the scrollviewer but the elements on the canvas to become smaller.

    Do you have any hint on how to achieve this?


           <ScrollViewer x:Name="TheScrollViewer" Grid.Row="0" CanContentScroll="True" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Auto">

               <Canvas x:Name="ScheduleCanvas" Width="{Binding ElementName=TheScrollViewer, Path=ActualWidth}" Height="{Binding ElementName=TheScrollViewer, Path=ActualHeight}">


                       <ScaleTransform CenterX="0" CenterY="0">


                               <Binding Mode="Default" Path="Value" ElementName="ZoomSlider"/>



                               <Binding Mode="Default" Path="Value" ElementName="ZoomSlider"/>






  6. Louis Abbott says:

    Great example, exactly what I was looking for!


  7. Bogac Guven says:

    That’s a great article, many thanks. Lets say we have a large area for interface, is it possible to zoom out or zoom in to where mouse pointer is?

  8. Bogac Guven says:

    I’ve found this article which achieves a similar result. Because I don’t have Visual Studio at work   I can’t play with its source code:


    You can see a part of the code in the link above. One thing is interesting, which is related to the question I’ve asked previously:

    <ContentPresenter RenderTransformOrigin="0.5,0.5">

    I guess by reading mouse position and giving it to RenderTransformOrigin in each render, zooming to/from mouse pointer position can be achieved.

    I’m a WPF newbie so I don’t know if it is feasible for your code Ivo.


  9. 話題の小向美奈子ストリップを隠し撮り!入念なボディチェックをすり抜けて超小型カメラで撮影した神動画がアップ中!期間限定配信の衝撃的映像を見逃すな

  10. Daisy says:

    This is great, thank you very much for sharing!

    I have just one question, is it possible to make zooming of the UI controles, like to deviating the buttons one from each other when zooming? That would be very useful to me, but I don't have idea how should I do that.. :/

  11. Ivo says:


    Yes, you can achieve that by adding an empty element (e.g. a grid row) between the buttons.

  12. .Net Team says:

    Is it possible not to resize the control while scaling?

  13. Ivo Manolov says:

    @.Net Team

    Certainly! You just apply the scale transform to a UI element (or container) that does not contain the control.

  14. Vlad says:

    It's amazing how far ahead of your time you are, you wrote this 7 years ago I'm just checking it out now!

    Thank you for your brilliance.

  15. Stefano Basili says:

    This article was very useful! Thanks man!

  16. Hausiusi says:

    Thank you man. That's what I looked for

  17. Ben says:

    Thanks for the useful tip! I am having a problem trying to scale a control (ListView) within a ScrollViewer within a Grid (within my User Control). I just want the ListView to scale, not the scroll bars of the parent, etc. However, changing the LayoutTransform of the ListView affects ALL other controls in the UserControl…. Weird thing is when I embed the WPF control in a Windows Form app… the scaling works correctly, the scrollbars don't scale with the ListView! Any idea what I might be missing?