Window themed using WindowChrome (for the Metro theme) shows completely transparent

Hi Hagay,

That's odd... does it resolve itself if you resize the window?

What happens if you upgrade your graphics card drivers to the latest?  If some low level WPF rendering is working some times but not others, it almost sounds like a bug in the driver.

That's odd... does it resolve itself if you resize the window?

No. Tried it as a W/A but no use.

What happens if you upgrade your graphics card drivers to the latest?

I will try but I'm pretty sure it is up to date.
Note that it doesn't happen if I don't use the WindowChrome.
What special about this chrome?

The only thing that is special is how we do the outer shadow for Metro themes only.  For that, we have to effectively show a second WPF Window that is "behind" the main chromed window in z-order.  It shouldn't really affect display of the main window though.  I'd be curious to know if you see it if you turn HasOuterGlow = false on the WindowChrome.  All non-Metro themes have that property false by default.

Well, I tried setting HasOuterGlow = false, but no use.

It still happens, and it happens not only on my computer but on others too.

The difference now (for the worse) is that, unlike visible in the screenshots I provided, there isn't even a thin border that implies the window is there.

What should I do next?

What if you are in a non-Metro theme, like AeroNormalColor.  Does it happen then?

Did you ever update your graphics card drivers to the latest?

Well... it seems not to happen when using AeroNormalColor theme.

What does it mean?

Per above, the only real difference between Metro and other themes is that Metro has the HasOuterGlow effectively true.  Setting WindowChrome.HasOuterGlow to false should make Metro behave like other themes.  Or alternatively putting this in your Application.Resources should do the same:

<system:Boolean x:Key="{x:Static themes:AssetResourceKeys.WindowHasOuterGlowBooleanKey}">False</system:Boolean>

Well....
I managed to have a shallow project that reproduces the problem and track down the exact code block that casing it! 

https://cyberbitsolutions-my.sharepoint.com/:u:/g/personal/hagay_myr_cyberbit_com/EbXEB6cBQkBMtSOslT6xUGcBVdjB-U4Zpmn1X4yqFrB2nw?e=sm22EW

Please run the app, mess with the "Show Image" CheckBox and click the "Show Dialog" button many times.
When unchecked, the DialogWindow renders just fine.
When checked, the DialogWindow start to sporadically not render at all.

You can see the code that actually seem to cause the issue under DialogWindow.cs:127.
Please disregard any "in-correctnesses" of the way stuff seem to be implemented by us.
It is a reproduction project and not necessarily exactly how stuff fully implemented.
In any case, this project is pure WPF and shouldn't be causing the described issue.

Please advise what should we do next...

Thanks!

Hi Hagay,

Thanks for the sample.  I believe I did see it happen once out of about 30-40 openings.  Do you have any tricks or sequences of actions that make it happen more often?

Hi Hagay,

Can you add this code to your Window before you set the WindowChrome up?

ThemeProperties.SetCornerRadius(this, new CornerRadius(1));

Let me know if that prevents it from happening.

Hi,

Regarding any special seuquence of actions - nothing, just open-close open-close till it happens.
For me (and others) it happens much much more frequently (once every 3-5 openings).

When I added that CornerRadius setup it didn't prevent it from happening, but I do feel it happens less frequently.

Hi Hagay,

I've been looking into this for a while and am unfortunately not coming up with much.  Other than a few settings like the corner radius, border thickness, outer glow option, etc. there shouldn't really be any difference in our logic based on theme.  I also haven't been able to repro it in your sample since I added that line I mentioned in the previous post.

What I did find is that another developer had the same issue using a competitive product that also makes custom chrome windows:

https://weblog.west-wind.com/posts/2017/Feb/13/Video-Rendering-Issues-for-WPF-Windows

It sounds like there is something deep down at a DirectX/WPF and/or hardware level that is occasionally triggering this issue.  The only workaround when this happens seems to be to trigger software rendering instead of hardware rendering.  You can do so at a registry level but that's probably not a good solution, as it would affect all WPF apps.  A better way is at app startup as mentioned in that thread:

protected override void OnStartup(StartupEventArgs e) {
  if (YourAppOptions.DisableHardwareAcceleration)
    RenderOptions.ProcessRenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;

  ...
}

Hi,

Thanks allot for the support and time invested.

I'll integrate your suggestion to provide a W/A for users that will need it.

However, as UI infrastructure providers, I hope that you'll provide some better solution in your future versions.

Thanks,
Hagay

Just a note to say we're still getting this issue fairly reguarly in our app that uses the WindowChrome.

It only happens for dialogs - it never happens for the main window of the application.

Currently the only viable solution for us is to not use the WindowChrome in dialogs (disabling hardware acceleration is not an option).

MG,

Some questions for you...

1)  Are you on the latest 2018.1 build?  If not, which version are you on?

2)  Which version of Windows are you on?

3)  Are you able to reproduce this reliably in a certain scenario or is it only sporadic?

4)  Does it only happen in Metro themes?  Does it happen if you start up the app with AeroNormalColor theme?

5)  If you put the following snippet in your App.Resources while in a Metro theme, does it still happen?

<system:Boolean x:Key="{x:Static themes:AssetResourceKeys.WindowHasOuterGlowBooleanKey}">False</system:Boolean>

Thanks for replying.

1. I am using 18.1.672.0.

2.  Windows 10, 1709, build 16299.666

3. It happens soradically in our production app, but I've just been able to reproduce it in a seperate app (e-mailed).

4. I only use the Metro theme currently (but you can change the demo).

5. Currently, I've added a class as per below. I'll try adding the key above.

public class ChromedWindow : Window
{
    protected ChromedWindow()
    {
        ThemeProperties.SetCornerRadius(this, new CornerRadius(1));
        WindowChrome.SetChrome(this, new WindowChrome()
        {
            HasOuterGlow = false
        });
    }
}

The demo app just shows a dialog 100-times in a loop (for 1 second). We see the occasional dialog that shows as transparent (this is the problem). Note that this happens in our production app on laptops and desktops (so a range of hardware).

Let me know if you have any ideas!

Just a few more notes.

• I've added the XAML declaration above but this doesn't resolve the issue.
• I've been able to reproduce it with the AeroNormalColor theme! So it's not MetroDark specific.

I've also been able to capture an animated gif (see e-mail) which shows the issue occuring (in the seperate app I e-mailed last week). You'll see the 3rd dialog is not rendered (only the progress bar which is animating is shown).

Thank you for the sample and animated gif.  I've run it on several PCs here a few times (and in different themes) and still haven't seen it happen though.  I'm not sure what the formula is to get this to happen here.  It must be somewhat hardware-dependent.  My desktop is running an nvidia card.  What is yours?

When debugging your app in VS as this scenario happens, do you ever see any error/exception data reported in the VS Output?

Also, have you tried using other .NET Framework reference versions to see if changing them to something newer/older makes any difference?

No problem.

We have reproduced it on a range of hardware, two examples are the NVIDIA Quadro K4000 (desktop), the NVIDIA Quadro K2100M (laptop) and the NVIDIA Quadro M2200 (laptop). I've also seen it in release builds and with the debugger attached when running in the IDE (I haven't seen any warnings but I'll look out for it).

We've also seen it on a range of .framework versions!

Whilst I can't say for certain, I strongly suspect it is something to do with the WindowChrome that is causing the issue because we have plenty of other WPF apps (some which use other custom window chrome) and they never exhibit this behaviour. Unfortunately, we did not purchase the source code so I can't look at it in any more detail.

Let me know if you have anymore ideas!

Just for the benefit of anyone looking at this thread, we have been working with MG offline on this since the last post.

Any updates?

Hi Hagay,

We are testing changes to WindowChrome out to try and narrow down what feature triggers it.  Unfortunately it's not easy since we ourselves can't repro it, and we have another customer who can repro it trying things out.  But even for them, it's not reliably reoccurring, so it takes a while to see if removing certain WindowChrome features does actually affect the issue.

Are there any new findings on this problem, we have the same sporadic problem?

Hi Artur,

Which version are you on?  We had worked with MG offline back around late 2019 and I believe together we made tweaks that should have helped with this.  We haven't had any reports of it since those updates went live.  If you are on an older version, please try v22.1.

Thank you for this information, we are using version 19.1.682 of ActiPro.

Hi Artur,

Yes, that version would have been before we did any updates in this area.  Please try v22.1 instead, thanks!