Favorite features in the June CTP

As the latest CTP shows, we are cranking along on WPF.  Most of our time is going towards bug fixing and improving performance.  Really important stuff, but not always terribly exciting for you to read about.  <g> But there are few genuine features that my “element services” team helped bring into the June CTP:

Hardware accelerated layered windows — yup, we’ve been working on this for quite awhile, it only took three of our best developers!  But I do need to throw in two caveats:

  • Windows Vista will support hardware accelerated layered windows, but we’re not sure about Windows XP.  We thought we had it working completely, and in June CTP hardware acceleration is supported on all operating systems.  But after we released the June CTP we found some serious problems on XP.  We’re currently trying to figure out if we can fix them without changing DirectX, which is obviously a problem on XP.  So while Vista is safe, it’s possible we’ll need to pull support for layered window acceleration on XP, I’ll let you know as we know more.

  • Even with acceleration, layered windows aren’t free, because we need to do more coordination with GDI than an opaque window. But it’s still a whole lot faster than software rendering. I haven’t done a lot of measurement, but ballpark is that if an opaque accelerated window is 10 times faster than software, an accelerated layered window is five times faster than software.

Window.AllowsTransparency — now you can create a layered window without using pinvoke, check out <http://laurenlavoie.com/avalon/162>

Xaml line numbers at runtime — If you have a legal xaml, and it’s the sort of error that gets caught at runtime rather than compile time, WPF wouldn’t tell you the line number — because xaml line numbers were thrown away after the compilation was done.  Until now, that is.  It’s not on by default, because we didn’t want to bloat your executable size, but if you put the following in your project file, you’ll get line numbers at runtime.

<!– under the <PropertyGroup> tag –>

GetValueSource — ever wonder where a property got its value from?  Try this:

ValueSource s = DependencyPropertyHelper.GetValueSource(button, Button.ForegroundProperty);

That will tell you the category where the value came from, eg:

    public enum BaseValueSource
        Default = 1,
        Inherited = 2,
        DefaultStyle = 3,
        DefaultStyleTrigger = 4,
        Style = 5,
        TemplateTrigger = 6,
        StyleTrigger = 7,
        ImplicitStyleReference = 8,
        ParentTemplate = 9,
        ParentTemplateTrigger = 10,
        Local = 11,
        ElementStoryboards = 12,

(There’s also flags for expression, animation, and coercion, which are really orthogonal steps in the property value calculation)

This is intended only as a debugging aid, please don’t make your program logic conditional on this.  Please don’t write a control that treats 5 differently if that 5 came from a style rather than the default value, that will confuse your users, and your code will break in future versions of WPF as we add more things to that enum.

Comments (10)

  1. Nick and Lauren have both

    blogged about one of the coolest &amp;quot;late&amp;quot; features in WPF: hardware-accelerated…

  2. Calve says:

    Wow, transparency support is cool 8)

  3. sfedorov says:

    I could not locate XamlDebuggingInformation(or anything even remotely similar) on a project’s property page. Should it be set using text editor then?

    Thank you

  4. Nick Ramer pr&#233;sente sur son blog les nouveaut&#233;s de cette version :

    – Les Layered Windows (fen&#234;tres semi-transparentes…

  5. JosephCooney says:

    I enabled Xaml error line numbers as described above (by manually editing the project file). It works, but all the error messages seemed to be on line 1 position 9, the end of the <Window element. The error always seemd to be "Cannot create instance of ‘<Window Class Name>’ defined in assembly …". To the credit of the WPF team I did have to try really hard to get run-time Xaml errors – most were caught at compile time. Maybe I’m just getting unimaginitive in my Xaml hacking.

  6. nkramer says:

    Sounds like you’re running into the issue of nested exceptions — check the inner exception, it should have additional information and a different line number corresponding to that additional information.  

    It’s fairly easy to create a xaml error that’s caught at runtime — pretty much anything inside quotes gets done at runtime.  My proof of concept sample was something like <Button Background="this is not a color"/>.

  7. Been porting a lot of code lately and the support for runtime XAML debugging to get line numbers has…

  8. Nick Ramer pr&amp;eacute;sente sur son blog les nouveaut&amp;eacute;s de cette version : – Les Layered Windows