We've had a number of rendering issues with NH Prof. I've been embarrassed about how frequently I have asked users to update their video drivers. It’s not surprising to encounter driver issues occasionally with WPF. It is built on top of DirectX you know. (In fact, all my WPF apps break horribly when I enable SLI mode.) However, too many people were reporting problems with NH Prof, and that led us to think that something else was going on.

During a shared coding session using Microsoft’s SharedView we noticed some of the graphical glitches that users were complaining about. This was important because we had not been able to reproduce any of these problems previously. Discovering this, I was able to create a sample application to help me isolate the problem. The symptom is garbled text. It’s interesting to point out that the text is only garbled when the window containing the text is over certain elements in other applications. Usually the culprit elements were the chrome bits of another window or control. Moving the offending window with garbled text would result in an effect that looked as if the text was transparent… Hmm…

Here is the Xaml sufficient to reproduce the issue:

<Window x:Class="GarbledTextTest.Window1"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Garbled Text Test"
        AllowsTransparency="True"
        WindowStyle="None"
        Height="300"
        Width="300">
    <Grid MouseLeftButtonDown="Grid_MouseLeftButtonDown"
          Background="Black">
        <TextBlock Text="Help me!"
                   FontSize="32"
                   Foreground="#cfff" />
    </Grid>
</Window>

(By the way, the event handler in the Xaml is just for me to drag the window around.)

But remember, I said that the developers were not experiencing the problem, so what else gives? I also mentioned that we noticed this while using SharedView. In fact, we fixed it in NH Prof during that same session. Something was special about SharedView. I recalled that SharedView used to tell me that it was disabling Aero when I started it (It doesn’t always do so, but I didn’t bother to find out why.) So I just disabled it myself by changing my theme back to Windows Classic.

Okay, so…

What does all this add up to? It seems that three different things stacked up to cause the rendering bug.

The first bit of wonkiness is the  AllowTransparency property on the Window element. If I set this property to false, the problem goes away. This wasn’t really an option for NH Prof as we preferred the custom chrome and need the transparency.

Second, the brush used for the text had partial opacity. It might not jump out at you, but the value #cfff translates to white with 80% opacity. If I make the brush 100% opaque, the problem goes away. That’s actually how we fixed it.

Of course, the third way was the doozy, and I can only qualify it as an Unhappy Rendering Environment. It might be an out of date driver, a remote desktop, your pretty Vista theme being disabled, or a picture of an angry monkey.

By the way, if you find any more of these glitches in NH Prof, please post about it in the forums. Also, there are other issues around rendering that are not related to this.