none
Refresh Problem with WPF Controls inside Winforms app (using interop) on Vista RRS feed

  • Question

  • Hi, I have a winforms application, where I want to start using WPF controls. This all seems to be working fine, using the ElementHost control to allow me to drop WPF onto windows forms.

    However, on one of the forms, there seems to be a major refreshing problem on Vista (I develop on XP, so did not notice it till someone ran the app on Visa)

    This is the basic setup (which I could reproduce in a simple sample app, which I wish I could attach) where the problem also occurs...

    1. I have a windows Form that has a large (e.g. 6000x6000) user control sitting on it. The Form is a lot smaller than this, so this give me a large (fixed) scrollable area (the Forms Autoscroll is set to true)

    2. Now, sitting on this large 6000x6000 user control, I have an ElementHost (not docked, and a lot smaller) , which holds a WFP control

    3. When I run this app on Vista, if I scroll using the Forms scroll bars, the WPF control has major paint problems. These fix themselves if you resize the window

    Does anyone know anything about this, and if there is any solution???

    It only appears to be on Vista. It does not occur on XP, and doesn’t appear to occur on a Windows 7 machine I briefly tired it on.

    Thanks in advance for any help
    Regards Peter

    Friday, August 21, 2009 4:42 AM

Answers

  • Hi all, just thought I'd post the reply, and workaround, I reeived from Microsoft connect. I have tried the workaround they suggested, and it solves the problem...

    This behavior is due to a limitation between DWM, GDI, GDI based ScrollViewer implementation, and DX (WPF). The DWM has two separate surfaces for GDI and DX content. The DWM composes those two surfaces together to render the window in the described scenario. When scrolling, Winform’s ScrollViewer (GDI based) moves parts of the visible area using the GDI BitBlit operation. That BitBlit operates exclusively on the GDI surface and therefore misses the DX (WPF) content. This leads to the behavior you see in your sample application because you are hosting DX (WPF) content inside of a Winforms (GDI) ScrollViewer.

    This issue should repro 100% on Vista. On Windows 7, it will only repro on certain hardware (older) and on multi-adapter configurations (not necessarily multi-mon).

    To work-around the limitation, you can drop WPF into software rendering by setting the HwndTarget.RenderMode property to RenderMode.SoftwareOnly.

    • Marked as answer by Peter-j-c Tuesday, May 25, 2010 1:44 AM
    Tuesday, May 25, 2010 1:44 AM

All replies

  • Hmm, no one else had this problem? :-( I do have a simple sample app I can send to anyone. I did try it on a number of vista machines in the office, and all seemt o have the problem. Strangely, it does not occur if you run the app over a remote desktop connection to a vista machine
    Tuesday, September 1, 2009 1:48 AM
  • Hi all, just thought I'd post the reply, and workaround, I reeived from Microsoft connect. I have tried the workaround they suggested, and it solves the problem...

    This behavior is due to a limitation between DWM, GDI, GDI based ScrollViewer implementation, and DX (WPF). The DWM has two separate surfaces for GDI and DX content. The DWM composes those two surfaces together to render the window in the described scenario. When scrolling, Winform’s ScrollViewer (GDI based) moves parts of the visible area using the GDI BitBlit operation. That BitBlit operates exclusively on the GDI surface and therefore misses the DX (WPF) content. This leads to the behavior you see in your sample application because you are hosting DX (WPF) content inside of a Winforms (GDI) ScrollViewer.

    This issue should repro 100% on Vista. On Windows 7, it will only repro on certain hardware (older) and on multi-adapter configurations (not necessarily multi-mon).

    To work-around the limitation, you can drop WPF into software rendering by setting the HwndTarget.RenderMode property to RenderMode.SoftwareOnly.

    • Marked as answer by Peter-j-c Tuesday, May 25, 2010 1:44 AM
    Tuesday, May 25, 2010 1:44 AM
  • This workaround doesn't work for Windows 10
    Friday, January 22, 2016 11:48 AM