Weird WPF WindowStyle behavior

I have a WPF window full of some WPF3D elements, and I decided when I maximized my WPF window, I'd like it to do more a 'fullscreen' display, and remove the various window dressings, so I did this:

protected override void OnStateChanged(EventArgs e)
{
if (this.WindowState == WindowState.Maximized)
{
this.WindowStyle = WindowStyle.None;
this.ResizeMode = ResizeMode.NoResize;
}
}

This takes the borders and titlebars off of my window, and it goes ahead and fills up the screen, respecting the windows task bars "auto-hide" and "on top" properties.

Only, the performance when animating my 3D objects was suddenly horrible, my CPU usage went through the roof, and the smooth animations i did have suddenly were < 1 FPS.

Changing the WindowStyle.None to anything else (SingleBorder, for example), didn't exhibit this problem.

I'd seen this terrible behaviour before, when playing with transparent windows - when you set WindowStyle to None, and AllowsTransparency=True, and all of your windows content is blended with the rest of your desktop - forcing a slow software rendering which has to test each and every pixel as it renders your desktop back to front, which is a heavily fill rate limited operation. It's a cute effect, but slow and worthless.

So I wondered, could something be setting AllowsTransparency=True internally, when I flip the WindowStyle = None switch? I placed AllowsTransparency="False" in the Window element of the .xaml file, and there was no change in behaviour.

I tried setting AllowsTransparency=false in code, right after changing the WindowStyle, and this throws an exception - as this property can only be set before the window is shown. So I put this line in the constructor, before InitializeComponent().

This fixed the issue - on my home machine - however it appears to remain on my machine at work.

This is weird all around. Explicitly setting it in code before InitializeComponent works, even though it is already explicitly set in the xaml - which does nothing. It works on a 32 bit Windows 7 machine with a ATI 4650 agp (WDDM 1.0 vista drivers), but seems to have no effect on a 64 bit Windows 7 machine with an NVidia card (WDDM 1.0 ).

I haven't peeked under the hood, but I'd chalk this up to Windows 7 growing pains, probably a bug in one or the other driver sets. This isn't the right way to do fullscreen with my emulator anyways (i should give the monitor over completely to DX), but certainly weird.

Shades of Gray

More of a note to self than anything else. After lots of head scratching with a shader .fx file I wrote, which compled fine with fxc, but would puke when loaded with the effect.FromStream() method in SlimDX, I eventually hit upon resaving it as ANSI (from unicode) and it worked.

Looks like this isn't unique to SlimDX, but an issue with the underlying CreateEffectFromXXX call to D3D9.

So:

UTF-8, Unicode - NO
ANSI - YES


Update: Visual Studio saves Unicode. A real fine how do you do from redmond.

WPF ResourceDictionary Insanity!!

So the short backstory is that I was messing around with the Media3D library, and had a bunch of .xaml files containing Model3DGroup's as top level elements. So I decided to merge them all into a resource dictionary.

I originally had some code to pull the models out, that looked something like this:

var p = TryFindResource("Sword") as Model3DGroup
if (p!=null) icon.Model=p;

Now, the xaml was littered with x:Name="" attributes, which are not allowed in a ResourceDictionary (but are allowed in a local Resources group). So the behavior I expected from a Try.... method would be to return null, rather than to get an exception.

However, it did throw an exception because of the x:Name="" attributes in the code. I stepped past the code in the debugger, and let it continue running because I wanted to see something else, and lo and behold - my model was there on the screen. The one that threw the exception.

So, creation of the Model from the resource throws an exception, but doesn't fail. TryFindResource therefore does not return null.

In the end, this crazy code works, and the type string will pop out the console, instead of the null you'd expect if the resource sort-of fails, even though the dictionary entries are malformed:

Model3D p = null;
try
{
p = TryFindResource("Sword") as Model3DGroup;
} finally {
}
Console.WriteLine(p);


This is not recommended, of course, and for the record I cleaned up the xaml in my dictionary.

This isn' t specific to the Media3D elements, it works the same for any old UIElement. I'm not sure what other sort of exceptions get thrown but don't cause the resolution to fail, I'm not sure if this behavior is by design or a bug - but I wouldn't rely on it. If the resource was referenced in xaml somewhere, the exception would cause the app to fail - even though the object that threw it is doing just fine.

One thing I do know, is that having to wrap a try around a Try___ is something that really grinds my gears.