Well, here is another piece of evidence!

The other day, a developer, Bruno Martinez, from Uruguay contacted me and wanted to contribute to Snoop by making it so that there was only 1 version, instead of the 4 currently required at that point.

If you recall …

1. You needed a version for WPF 3.5 and 32-bit.
2. You needed a version for WPF 3.5 and 64-bit.
3. You needed a version for WPF 4.0 and 32-bit.
4. You needed a version for WPF 4.0 and 64-bit.

Yuck! Of course, it was better than not being able to Snoop in those situations.

Well, after integrating Bruno’s changes … you just need:

1. Snoop

Yeah, that’s right. There are no labels! Thank you, Bruno!

I’m obviously tickled by this … since it was a usability nightmare trying to figure out what version you needed to run … but there are host of other fixes/improvements as well. In particular, the Snoop start-up process is much more robust than it used to be and it can handle some fringe cases that it wasn’t able to before.

Please go to http://snoopwpf.codeplex.com for more info, and of course, the download/release area for version 2.6.0.

Happy Snooping!

Share/Save

In some xaml files, I had no folding editor … and no IntelliSense!

What I discovered was that if I delete the local namespace declaration (and then add it back again), the folding editor starts working again.

Then, I discovered that if I just leave out the local namespace declaration … instead of adding it back, IntelliSense starts working again. Annoying … since I have to remember to put the namespace declaration back before checking it in.

So, I decided to do a search and see if anyone (besides me) had run into this problem. Well, as you all know, the trick to searching for anything on the internet is getting the right search string. Well, I got lucky. This search brought me to this blog post.

It wasn’t exactly my problem, but what I found was that if I added an ‘;assembly=’ to my local namespace declaration … everything started working again … and would continue working even if I closed and reopened the file! Woot!

So, the following xaml doesn’t work:

<my:Inspector
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:my="clr-namespace:Snoop"
    x:Class="Snoop.PropertyGrid2"
    x:Name="PropertyGrid"
    MinHeight="0"
    MinWidth="0"
>

But, the following xaml DOES work:

<my:Inspector
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:my="clr-namespace:Snoop;assembly="
    x:Class="Snoop.PropertyGrid2"
    x:Name="PropertyGrid"
    MinHeight="0"
    MinWidth="0"
>

Hope this helps someone! It has bothered me for some time!

p.s.
Just to clarify: this does not affect Visual Studio 2010. That is, you do not need the ‘assembly=’ there … so this was likely an issue with the xaml editor in Visual Studio 2008.

Share/Save

If you try to Snoop a WPF 4.0 application with the WPF 3.5 version, you will get the following error message:

I speculate that this is because there is a brand new CLR with .NET 4.0 (WPF 4.0) applications. Yes, that’s right, a brand new CLR. We haven’t had one of those for a while.

If someone can confirm this or provide a better understanding of why I can’t Snoop WPF 4.0 applications without retargeting Snoop to .NET 4.0 … please shed some light for me.

So, there are now 4, count them, 4 versions of Snoop:

1. Snoop 32-bit for WPF 3.5
2. Snoop 64-bit for WPF 3.5
3. Snoop 32-bit for WPF 4.0
4. Snoop 64-bit for WPF 4.0

You need to use the right version of Snoop in each particular situation … otherwise … thar will be problems, matey!

I have also added another label to the app chooser so that you know which version you currently have up. Take a look … this is what it looks like for the 64-bit/WPF 4.0 version:

Let me know if you have any problems by creating a discussion (or participating in a current one) on the http://snoopwpf.codeplex.com site.

Enjoy and happy Snooping!

Share/Save

Snoop is now on CodePlex at snoopwpf.codeplex.com

The community reception to my efforts (blog posts: 1, 2, 3) on Snoop have been wonderful. Some like Anvaka have offered additional feature suggestions; others have just encouraged me.

In my last post, a fellow commented asking why it wasn’t up on CodePlex. Well, this was a great suggestion and one that I had actually already considered. That prompted me to email Pete Blois (the original author) for his permission. He graciously gave it and so I then proceeded to put it up there.

It took me a little while, but I now have the initial bits uploaded … that is, the same stuff that is available here at my blog.

Now, there are a bunch of things on the todo list. Most notably, I’ve already modified Snoop so that it works for WPF 4.0 … and definitely want to share that with the world.

So, please be patient, I’ll get to it. Those silly day jobs!

Some Info

If you are going to download the source code and build it, some comments are in order (I’ll put this out at the CodePlex site too).

There are (go to Build->Configuration Manager) 3 solution platforms (x86, x64, Any CPU) and 2 solution configurations (Debug, Release). The x86 platform is for 32-bit, the x64 platform is obviously for 64-bit, but … what is Any CPU?

Well, Any CPU is only around for Blendability. That is, for some odd reason, I couldn’t bring up the Blend designer Snoop’s window unless it was in this configuration. I have intentionally marked the ManagedInjector project to not be built under the Any CPU configuration. Since Any CPU will run as 32-bit on 32-bit operating systems and as 64-bit on 64-bit operating systems, using Any CPU will likely cause a mismatch (and a headache ) with the ManagedInjector dll.  The project which builds the ManagedInjector.dll is a C++ project and there isn’t an Any CPU setting for those (they can only be specifically built to Win32 or x64).

Or, in other words, make sure you switch into another platform, before you build or the build will fail.

Here’s a chart for quick reference:

Call to Action

If you have a feature request or want to be involved somehow (maybe as a contributor), please don’t hesitate to contact me.

For near future though, I’m going to keep the project closed until I can change the copyright info to Ms-PL and clean up the code a bit.

Thanks

Finally, I want to publicly thank Pete Blois for first creating this awesome tool and for giving us the permission to get it going on CodePlex. A big thanks Pete!

Share/Save

I’ve done this many, many times because it is the only way I’ve been able to Snoop applications on my Windows 7 64-bit operating system. And, I thought, “Boy, this is stupid. I should be able to build a 64-bit version of Snoop such that I don’t have to do this anymore.”

And that is exactly what I did.

Now … presenting Snoop 32-bit!

And Snoop 64-bit!

Here are the binaries for the 32-bit version and here are the binaries for the 64-bit version.

(The binaries are now (see posts: 1, 2) up on CodePlex. Please go download it from there as those binaries will contain the latest and greatest bits.)

It was rather a simple matter really. I just needed to change all the project configurations so that they targeted the x64 platform … for the x64 version of Snoop … and all the project configurations so that they targeted the x86 platform … for the x86 version of Snoop.

This was so easy and worked so nicely … that I searched the internet to see if anyone had done this already … and I found Dan Hanan’s nice post on the matter.

The problem, though, was that he did it for original version of Snoop … and not the nicely styled and improved version that Pete Blois currently is making available since property editing was originally (still?) broken in that version. However, he also had several nice usability features that I was drooling over and wanted for my very own. And I, of course, have already fixed the property editing issue in my version (see previous posts: 1, 2) with a little help from Mark Kharitonov (see this forum post for more info on that).

So, I emailed him, got his permission to integrate those changes, and promptly did so. I also added a few improvements myself.

The Improvements

Here is what has been improved (over and above Pete Blois’ current version):

Improvement	Originator
Handles WPF interop scenarios (both Windows Forms hosting WPF and WPF hosting Windows Forms).	Cory Plotts
Fixed the ability to edit properties.	Mark Kharitonov
Modified Snoop so that it can handle visual trees that have nesting greater than 255 levels deep.	Mark Kharitonov
Modified the project configurations so that you can build a 32-bit version and a 64-bit version. This is what the blog post is all about! Ha!	Cory Plotts Dan Hanan
Turned off the showing of properties at their default value (by untoggling the Show Defaults toggle button).	Dan Hanan
Turned auto refresh off in the AppChooser. Snoop was previously polling every 20 seconds for new applications.	Dan Hanan
Added a checkbox to turn auto refresh back on (if you so desire).	Dan Hanan
Added a label to the AppChooser to indicate 32-bit versus 64-bit.	Dan Hanan
Added a wait cursor when the AppChooser is busy iterating over the applications to possibly Snoop.	Dan Hanan
Added the capability to bring the selected tree view item into view.	Dan Hanan
Added the capability to filter properties based on predefined sets of properties.	Dan Hanan
Added the ability to pop the target (after a delve) with the back button on the mouse.	Dan Hanan
Modified the selected item in the tree view to be a light blue even when it doesn’t have focus.	Dan Hanan
Added the ability to pop the target (after a delve) with the alt-left arrow keyboard sequence.	Cory Plotts
Added the ability to remember window position, size, and the maximized/minimized/normal state for all three Snoop windows.	Cory Plotts
Removed the filtering of ‘devenv’ out from the list of applications that you can Snoop.	Cory Plotts
Modified the project configurations so that it never builds the installer. I just copy the Snoop executable and the ManagedInjector dll from place to place. Don’t know if this an improvement.	Cory Plotts
Fixed the x86 installer and created an installer for x64. Snoop is no longer being added to the GAC and the assemblies are thus no longer strong named. The installers for both platforms should now work.	Cory Plotts
Integrated Anvaka’s great suggestion below (see the comments). That is, I moved the long label that tells a user how to ctrl-shift click on the application being Snoop(ed) (to a tool tip on the tree view) … and replaced it with a label that tells the user what the immediate following hyperlink is … that is, the Keyboard.FocusedElement. Also added another label and hyperlink for the current selection’s focus scope.	Andrei Kashcha (Anvaka)

I chose not to integrate a couple of Dan Hanan’s changes. First, I did not integrate the ‘indexer delve’. Well, actually I did, but then noticed that Pete Blois’ new version already allowed you to delve into items in a collection … and so I backed it out.

Second, I did not integrate the ‘use 2nd monitor if present’ feature. I liked that feature but thought that I would try to improve upon it by remembering the position and size of all the windows … regardless of the number of monitors. So, with a little help from this StackOverflow question and this MSDN sample … that is what I did. It seems to work nicely. Let me know if you have any problems with it.

Snoop(ing) Visual Studio 2010

Finally, ever since I’ve installed Visual Studio 2010, I’ve wanted to take a peek under the covers with Snoop (remember … Microsoft used WPF in this latest version of Visual Studio). I originally thought I couldn’t Snoop it … because it was running as a 64-bit application and I only had a 32-bit version of Snoop.

So, when I got the 64-bit version of Snoop going, I quickly tried Snooping Visual Studio 2010. No luck! Bringing up task manager, I quickly remembered that Visual Studio runs as a 32-bit application on 64-bit operating systems. See this post by Rico Mariani for more info.

As I have recently been invited into the WPF Disciples group, I posed the question there. Imagine my surprise to find out that devenv.exe was manually being filtered out (since Visual Studio 2008 would load WPF assemblies … but Snoop would fail since Visual Studio 2008 wasn’t built with WPF).

That gave me quite the chuckle. Or, more like, duh! So, promptly removed that and Snoop(ed) Visual Studio 2010 to my delight (check out the red Snoop adorner):

And, of course, the Snoop AppChooser:

And, finally, the main Snoop user interface:

I think that is so cool. Ok, I know … I need mental help.

The Source Code

In the past, I have not released the source code since I have wanted to get Pete’s permission before I do so. I actually met him at PDC 2009 this year. I brought up the fact that I had modified Snoop to handle interop scenarios … but I forgot to ask him about the source code!

There are so many changes now … that I think it would be counter-productive to not release it … in case someone else wants to take Snoop even further than I (and Dan and Mark) have. If you do modify it … and take it further … please let me know! I would love the chance to determine whether to integrate the changes into this version.

So, here it is: the source code.

(The source code is now (see posts: 1, 2) up on CodePlex. Please go download it from there as that code will contain the latest and greatest bits.)

Enjoy!

p.s. If you were one of the few who pulled down the binaries immediately after I posted it, then you may not have gotten the Snoop.exe.config file. Unfortunately, in this case, Snoop does not seem to close down all the way (i.e. I had to manually kill it through task manager). You’ll want to get the latest binaries that do include the Snoop.exe.config file … or manually rebuild them yourself with the source code.

An Update

See above (in the table of improvements), but I fixed the installers and integrated a nice idea by Anvaka. All the attached binaries (which should be installers now) and source code have been updated.

Share/Save

Hue, Saturation, Color, and Luminosity: Where Are You?

If you were watching closely, you will have noticed that I have not (to date) implemented the Hue, Saturation, Color, and Luminosity blend mode effects.

Why is that? Whenever fxc.exe would compile the .fx file (through the Shader Effects BuildTask and Templates), it would give me the following two errors:

• error X5608: Compiled shader code uses too many arithmetic instruction slots (100). Max. allowed by target (ps_2_0) is 64.
• error X5609: Compiled shader code uses too many instruction slots (102). Max. allowed by the target (ps_2_0) is 96.

Those errors mean that you’ve exceeded the limitations of Pixel Shader 2.0 … which is what WPF 3.5 SP1 targets for pixel shader effects.

So, what can you do about this? You could optimize the HLSL so that your effect code goes under the limits … but if you notice in the errors above (these particular errors are for the Saturation effect) … you will see that I am significantly above the number of allowed arithmetic instruction slots (100 versus 64). I would have to optimize significantly.

WPF 4.0 to the Rescue

Another option is to utilize WPF 4.0!

WPF 4.0 increases what you can do with effects because it now allows you to target Pixel Shader 3.0. This wikipedia article has a great chart on the differences between the different shader models. With PS 3.0, we shouldn’t hit any limits.

Realizing this, as soon as Visual Studio 2010 and .NET 4 Beta 2 came out (PS 3.0 is only available in Beta 2), I installed it and gave it a whirl. There was really only one gotcha in getting this to work. The Shader Effects BuildTask only compiles to PS 2.0 … and there is no option to toggle between PS 2.0 and PS 3.0.

This means that, for now, probably until release, you will have to manually run fxc.exe (targeting ps_3_0) and add the compiled shader output file (the .ps file) to the project as a Resource.

Caveats

There are some caveats to using PS 3.0 in WPF 4.0. Most notably, there is no software fallback if your hardware or situation (remote desktop, forced software rendering) don’t support it. This means that your effect code will simply not run and not appear.

Some good news is that Microsoft has extended the RenderCapability API so that you can determine what level of pixel shader support is currently available. They’ve updated the RenderCapability.IsPixelShaderVersionSupported method and have added two additional methods: RenderCapability.IsPixelShaderVersionSupportedInSoftware and RenderCapability.MaxPixelShaderInstructionSlots.

(The above information and more is available in David Teitlebaum’s PDC09 session titled Mastering WPF Graphics and Beyond. Jamie Rodriguez also has some great posts covering what’s new in WPF 4.0 (Beta 1, Beta 2).)

Another caveat that bears mentioning is that Silverlight (both 3.0 and 4.0) only support PS 2.0. So, if you are creating and using effects across both technologies, you will not be able to use PS 3.0. This also means that the Hue, Saturation, Color, and Luminosity blend modes (and the attached code) are WPF only blend modes. Sorry Silverlight! I love you, but that’s how the chips fall.

Hue, Saturation, Color, and Luminosity: Here They Are!

Alright … enough with the caveats! Let’s see the effects!

First, let me refer you back to Angie Bowen’s post where she covers what each blend mode does … including the Hue, Saturation, Color and Luminosity effects.

To show off what each effect does, I’m going to go ahead and use her reference images … first showing how they blend out of Photoshop … and then showing how they blend with my library … for comparison purposes. Why? Well, it seems as if my blend mode library does not always match what is coming out of Photoshop … sometimes it’s pretty darn close and at other times it’s more than just a little bit off.

I have been through and through the math (and HLSL) for these effects and I honestly can’t find anything wrong there. If I could speculate what is going on, I would say that I’m bumping up against some float versus double precision issues (where Photoshop is using doubles for greater precision) during the conversion from RGB to HSL and back. If you can figure out what I’ve done wrong (if anything) please let me know.

However, for the most part, they work great!

Hue Blend Mode

The result is the hue of the blend layer and the saturation and luminance of the base layer.

Photoshop
My Blend Mode Library

Photoshop
My Blend Mode Library

Saturation Blend Mode

The result is the saturation of the blend layer and the hue and luminance of the base layer.

Photoshop
My Blend Mode Library

Photoshop
My Blend Mode Library

Color Blend Mode

The result is luminance of the base layer and the hue and the saturation of the blend layer.

Photoshop
My Blend Mode Library

Photoshop
My Blend Mode Library

Luminosity Blend Mode

The result is hue and the saturation of the base layer and the luminosity of the blend layer.

Photoshop
My Blend Mode Library

Photoshop
My Blend Mode Library

The Binaries and the Source Code

Here is the source code for the library and here is the assembly.

Again, remember that this is a WPF-only release as Silverlight does not yet have support for Pixel Shader 3.0.

Also, all of these new blend modes are opacity aware … meaning that you can pull the opacity out of the upper layer to lessen the effect of the blend mode (see my last post on the matter).

Enjoy!

p.s.

At one point, I thought that the Shader Effects BuildTask and Templates was built into Visual Studio 2010. It appears I was mistaken about that. I have updated this post to indicate that.

Share/Save

The Problem

… and noticed that it didn’t handle an opacity changes on the upper layer (B).

In fact, this was brought to my attention by a great blog post by Angie Bowen. In it she explains how the blend modes work and, she says:

Remember that to get better results you can also adjust the opacity of the upper layer.

Trying it out, revealed that some of the blend modes were okay, but most were not. Most of the blend modes would simply result in a black square if you pulled all the opacity out of the upper layer (B). This was obviously wrong, for if you pull all the opacity out of the upper layer (B), you should get the lower layer (A).

Argh!

The Solution

So, I dove back in on the blend mode math, trying to figure out what I needed to do to make these blend modes … opacity aware. That’s got a nice ring to it, doesn’t it!?

I started at the top of the list and got the NormalEffect working:

float4 main(float2 uv : TEXCOORD) : COLOR
{
    float4 inputColor;
    inputColor = tex2D(input, uv);

    float4 blendColor;
    blendColor = tex2D(blend, uv);

    inputColor.rgb = (1 - blendColor.a) * inputColor.rgb + blendColor.rgb;

    return inputColor;
}

Ok, the above math made sense. When the opacity of the upper layer (blendColor.a) was 1 (opaque), the result was just blendColor. Otherwise when the opacity of the upper layer was 0 (transparent), the result was inputColor.

So, I then started to tackle the darken blend modes (Darken, Multiply, …) and quickly ran into problems. It was at that point, that I ran into this post in the WPF Forum. My blend modes were rendering full black (not white), but it provided a crucial piece of knowledge.

Namely, WPF uses pre-multiplied alpha everywhere for performance reasons.

What does that mean? Well, it means that the RGB values for inputColor are already multiplied by the alpha value for inputColor and that the RGB values for blendColor are already multiplied by the alpha value for blendColor.

Ah! Do you see it? This explains why the blend modes were going to a black square when pulling the opacity out. Take the Multiply blend mode. In the above HLSL, it would be:

// R = Base * Blend
resultColor.rgb = inputColor.rgb * blendColor.rgb

So, if the alphas were pre-multiplied in and you were pulling opacity out of the blend (upper) layer … then blendColor.rgb would go to zero … which would cause resultColor to go to zero … which would cause the gradient square to go to black!

Thinking about this … brought about the general solution for making these blend modes opacity aware. I needed to simply:

1. Un-pre-multiply the blend layer alpha value out.
2. Apply the blend mode math.
3. Then re-multiply the blend layer alpha value in again.

Here is the HLSL for the opacity aware Multiply blend mode:

float4 main(float2 uv : TEXCOORD) : COLOR
{
    float4 inputColor;
    inputColor = tex2D(input, uv);

    float4 blendColor;
    blendColor = tex2D(blend, uv);

    float4 resultColor;
    resultColor.a = inputColor.a;
    // un-premultiply the blendColor alpha out from blendColor
    blendColor.rgb = clamp(blendColor.rgb / blendColor.a, 0, 1);

    // apply the blend mode math
    // R = Base * Blend
    resultColor.rgb = inputColor.rgb * blendColor.rgb;

    // re-multiply the blendColor alpha in to blendColor
    // weight inputColor according to blendColor.a
    resultColor.rgb =
        (1 - blendColor.a) * inputColor.rgb +
        resultColor.rgb * blendColor.a;

    return resultColor;
}

A few comments about the above code. Notice that I am clamp(ing) when I un-premultiply (i.e. divide) the alpha out. This assures that the RGB values will be between 0 and 1 (where 0 is black and 1 is white … HLSL operates in ScRGB color space). This is necessary since dividing by values close to 0 (blendColor.a) can yield large numbers or even positive infinity … which throws off the math.

Secondly, when I re-multiply the blend layer alpha value back in … I need to also properly weight the inputColor … just like I did in the NormalEffect above.

Finally, notice that I really don’t have worry about the opacity on the lower layer (A). I just pass its value off to the result by setting resultColor.a equal to inputColor.a.

Applying this general formula worked in all cases!

The Gradient Contour Test Harness

In order to verify that I was doing math correctly, and to see the effect of pulling the opacity out of the blend modes … I have built a new gradient test harness. I have called it the gradient contour test harness since it not only shows the A + B = R gradient squares but it also shows the R gradient square with contours … just like Paul Dunn’s post does when you mouse over the R squares.

It is extremely interesting (to me at least) watching the contours as you pull out the opacities.

For example, Here are three gradient contour squares for the Pin Light blend mode at opacity values of 1.0, 0.5, and 0.0:

Gradient Squares	Gradient Contour Squares	Opacity
		1.0
		0.5
		0.0

I have also included a button labeled ‘Swap’ which swaps the A and B layers … since not all blend mode effects are commutative.

The gradient contours were made possible via Dwayne Need’s library. Check out the code (the class Grayscale4Bitmap) and see this post for more info.

The Image Test Harness

I’ve also put opacity sliders in the image test harnesses. Let’s take a look at the Pin Light effect at opacity values of 1.0, 0.5, and 0.3.

Images	Opacity
	1.0
	0.50
	0.3

As you can see … pulling out the opacity … lessens the effect that the upper layer/texture has on the lower layer … and proves the truth of what Angie Bowen was saying earlier about using the opacity of the upper layer to achieve better results.

The Binaries and the Source Code (aka The Goods)

So, as I’m fond of saying … without further adieu … here is source code for the Blend Mode library and here are the library binaries … now opacity aware!

I also have updated the Silverlight test harness (as always you will need the Silverlight 3.0 runtime).

p.s.

The gradient contour test harness is WPF only … you won’t find that on the Silverlight side. Maybe someday I’ll get my Silverlight test harnesses up to parity with what’s in the WPF test harnesses … but I can’t see when. Any one want to do it for me? Bueller? Bueller?

Share/Save

A small aside: I think it is what I was meant to do (i.e. work on graph controls). For, my name is … Cory Plotts. Plotts, you know, as in plots. Ok, never mind, that was lame.

So, it was quite natural, and actually part of my job, to take a look at what Microsoft is offering in the WPF and Silverlight toolkits. I have to hand it to David Anson and the other fellows at Microsoft. They have taken a very nice approach.

First, almost everything is a System.Windows.Controls.Control that you can restyle and re-template to your heart’s content. So, that makes it very designable.

Second, I love the data binding model. They have decided to follow an ItemsControl like approach where you have an ItemsSource property that you just plunk your data into. Very nice. It literally takes you seconds to get something up and running.

Third, they are developing it … with Blend in mind. That is, they are trying to provide a positive Blend experience and have gone to pains to make it so. So, not only is it designable … but designers can actually use Blend to do their designing … instead of hacking through xaml in a code editor. Woot! Woot!

Now, this post is not going to be an introduction on how to start using the charting component. Many others have done that already. If that is what you are looking for … I would suggest that you go to this blog post by David Anson where he lists out lots and lots of links to other blog posts and articles. In fact, he is so nice … that he has even separated them out by difficulty level.

No, in this blog post, I am going to show you the fourth thing I love about this charting component: how extensible it is! And, I am going to do that by showing how I created a logarithmic axis by simply deriving from NumericAxis.

So, here’s the code (sorry for just dumping it all in one place … but it gives you a nice place to copy out the entire implementation at once):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Shapes;

namespace System.Windows.Controls.DataVisualization.Charting
{
    /// <summary>
    /// An axis that displays numeric values along a logarithmic range.
    /// </summary>
    [StyleTypedProperty(Property = "GridLineStyle", StyleTargetType = typeof(Line))]
    [StyleTypedProperty(Property = "MajorTickMarkStyle", StyleTargetType = typeof(Line))]
    [StyleTypedProperty(Property = "MinorTickMarkStyle", StyleTargetType = typeof(Line))]
    [StyleTypedProperty(Property = "AxisLabelStyle", StyleTargetType = typeof(NumericAxisLabel))]
    [StyleTypedProperty(Property = "TitleStyle", StyleTargetType = typeof(Title))]
    [TemplatePart(Name = AxisGridName, Type = typeof(Grid))]
    [TemplatePart(Name = AxisTitleName, Type = typeof(Title))]
    public class LogarithmicAxis : NumericAxis
    {
        /// <summary>
        /// Instantiates a new instance of the LogarithmicAxis
        /// </summary>
        public LogarithmicAxis()
        {
            ActualRange = new Range<IComparable>(1.0, 2.0);
        }

        /// <summary>
        /// Returns the plot area coordinate of a value.
        /// </summary>
        /// <param name="value">The value to plot.</param>
        /// <param name="range">The range of values.</param>
        /// <param name="length">The length of the axis.</param>
        /// <returns>The plot area coordinate of the value.</returns>
        protected override UnitValue? GetPlotAreaCoordinate(object value, Range<IComparable> range, double length)
        {
            if (value == null)
            {
                throw new ArgumentNullException("value");
            }

            if (range.HasData)
            {
                double doubleValue = ValueHelper.ToDouble(value);
                Range<double> actualDoubleRange = range.ToDoubleRange();

                return
                    new UnitValue
                    (
                        length /
                        Math.Log10(actualDoubleRange.Maximum / actualDoubleRange.Minimum) *
                        Math.Log10(doubleValue / actualDoubleRange.Minimum),
                        Unit.Pixels
                    );
            }

            return new UnitValue?();
        }

        /// <summary>
        /// Returns the value range given a plot area coordinate.
        /// </summary>
        /// <param name="value">The plot area position.</param>
        /// <returns>The value at that plot area coordinate.</returns>
        protected override IComparable GetValueAtPosition(UnitValue value)
        {
            if (ActualRange.HasData && ActualLength != 0.0)
            {
                if (value.Unit == Unit.Pixels)
                {
                    double coordinate = value.Value;
                    Range<double> actualDoubleRange = ActualRange.ToDoubleRange();

                    double output =
                        Math.Pow
                        (
                            10,
                            coordinate *
                            Math.Log10(actualDoubleRange.Maximum / actualDoubleRange.Minimum) /
                            ActualLength
                        )
                        *
                        actualDoubleRange.Minimum;

                    return output;
                }
                else
                {
                    throw new NotImplementedException();
                }
            }

            return null;
        }

        /// <summary>
        /// Returns a sequence of values to create major tick marks for.
        /// </summary>
        /// <param name="availableSize">The available size.</param>
        /// <returns>A sequence of values to create major tick marks for.
        /// </returns>
        protected override IEnumerable<IComparable> GetMajorTickMarkValues(Size availableSize)
        {
            return GetMajorValues(availableSize).Cast<IComparable>();
        }

        /// <summary>
        /// Returns a sequence of values to plot on the axis.
        /// </summary>
        /// <param name="availableSize">The available size.</param>
        /// <returns>A sequence of values to plot on the axis.</returns>
        protected override IEnumerable<IComparable> GetLabelValues(Size availableSize)
        {
            return GetMajorValues(availableSize).Cast<IComparable>();
        }

        /// <summary>
        /// Returns a sequence of major axis values.
        /// </summary>
        /// <param name="availableSize">The available size.</param>
        /// <returns>A sequence of major axis values.
        /// </returns>
        private IEnumerable<double> GetMajorValues(Size availableSize)
        {
            if (!ActualRange.HasData || ValueHelper.Compare(ActualRange.Minimum, ActualRange.Maximum) == 0 || GetLength(availableSize) == 0.0)
            {
                yield break;
            }

            yield return 125;
            yield return 250;
            yield return 500;
            yield return 1000;
            yield return 2000;
            yield return 4000;
            yield return 8000;
        }
    }
}

To explain the above code a little bit, I would first direct your attention to two methods. The first is called GetPlotAreaCoordinate. This method is the method responsible for converting from world coordinates into device coordinates. That is, it converts all the data point values in your Series into pixel coordinates … so that your data point is placed where you expect it should be.

The second method is called GetValueAtPosition. This method does the exact opposite as GetPlotAreaCoordinate. It converts from device coordinates into world coordinates. In other words, it takes the mouse position (for example) and it tells you where your mouse is at on the respective axis.

So, the above two methods contain the math behind the axis … and if you look closely, you’ll see the Math.Log10 function getting called. Yep. That’s right. This is a logarithmic axis.

After those two methods, you will see GetMajorTickValues and GetLabelValues. They both delegate to a third method called GetMajorValues. GetMajorTickValues returns the values at which we want major tick marks and GetLabelValues returns the values at which we want grid line labels. Pretty straightforward.

Now, a word about my implementation of GetMajorValues. In it, I have chosen to hardcode very specific values for this axis’ grid lines (i.e. 125, 250, 500, 1000, 2000, 4000, 8000). I did that because I was lazy. For inside of LinearAxis, there is an Interval property which you can use to generate the grid lines in a dynamic fashion … and I didn’t feel like figuring out how to make the Interval property work for the logarithmic axis. (If anyone out there does take the time to do so … please share!)

So, more than likely, you will be wanting to replace those specific values with some of your own … or will be wanting to generate the major values in a much more dynamic way.

Ok, now let me show you how you would use this axis. Check out this xaml (this is just a snippet … I am leaving out all the styling xaml and more):

<charting:Chart
    x:Name="chart"
    Width="480"
    Height="480"
    Margin="10"
    Title="Response"
    BorderBrush="{x:Null}"
    Style="{StaticResource chartStyle}"
>
    <charting:Chart.Axes>
        <charting:LogarithmicAxis
            Orientation="X"
            ShowGridLines="True"
            Title="Frequency (Hz)"
            Minimum="100"
            Maximum="10000"
        />
        <charting:LinearAxis
            Orientation="Y"
            ShowGridLines="True"
            Title="Response (dB SPL)"
            Minimum="20"
            Maximum="120"
            Interval="10"
        />
    </charting:Chart.Axes>
    <charting:LineSeries
        ItemsSource="{StaticResource responseCurve}"
        IndependentValueBinding="{Binding Frequency}"
        DependentValueBinding="{Binding Response}"
        DataPointStyle="{StaticResource lineDataPointStyle}"
        AnimationSequence="Simultaneous"
        TransitionDuration="0:0:0"
        IsSelectionEnabled="True"
    />
</charting:Chart>

In the above, you can see my new and proud LogarithmicAxis with a Minimum value of 100 and a Maximum value of 10000. Here is a snapshot of the chart that the above xaml creates:

Woot! Doesn’t it look sweet!

Now, go out and create some logarithmic charts!

p.s.

I have had to make these changes in a local edit of the toolkits. However, as David Anson points out in this post … they are unsealing everything! So, in a little while … you will no longer need to do this. You will be free to simply derive a new axis at your leisure. In my mind, that is another point for extensibility!

p.s.s.

Here is the source code for this article … note that it contains David Anson’s development release version 1 … and it contains his DataVisualizationDemos applications. Finally, and most importantly for this article, it contains the sample code for the above … under the title Visibility (I was working on some DataPoint visibility functionality at the time I drafted up that test harness).

p.s.s.s.

David Anson and the fellows at Microsoft have finally released the version of the Silverlight Toolkit that unseals everything. Check out this blog post for more info. When David publishes another development release, I’ll update the source code for this article so that the above is not a local edit.

p.s.s.s.s.

I have finally gotten around to getting the source code together where the above logarithmic axis is just an extension of toolkit … versus the local edit as before. So, here is that source code. It is actually from David Anson’s development release 3 (although I have stripped out the WPF 4 and Silverlight 4 projects). I won’t remove the above source code … as some people might want to see both ways of doing it.

One additional comment. In David’s development release 2, there was an internal NumericAxis constructor. So, even though he unsealed everything, that internal constructor was inhibiting me from inheriting a new numeric axis type via an extension. That meant I had to wait till development release 3 in order to provide this code. (I also had to find some time too. )

Share/Save

I just received my copy of the masterpiece WPF Control Development Unleashed in the mail. Woohoo!

Written by the veritable master Pavan Podila with a little help from Kevin Hoffman, it is sure to be an instant classic.

Why is that?

Well, WPF is known for its learning curve. In particular, the amount of concepts that you have to digest in order to create custom elements and controls … is rather daunting.

This book will ease your journey. Even more, this book will give you the insight and the tricks to deliver compelling user experiences.

You know me, the presentation layer is my passion, and in particular, building controls is what I love to do. This book was meant for me. In fact, I was honored to help review a few of the chapters and now that I have it in front of me … I’m going to devour the rest of it. Who knows, maybe I will start up a series of blog posts as I go along.

Muhawhahaha! World domination! With this in my hands, the world is mine! All mine!

Share/Save

In this third blog post in the series (Part 1 and Part 2), I will explore these limitations and show you how you can use Jeremiah Morrill’s GlassBehavior (which with his permission I have renamed to BackgroundEffectBehavior) to get around some of them.

Let’s jump in.

Sometimes you’ll have two images of the exact same size that you want to blend together using one of the blend modes in my library. That is:

<!-- Blending Two Images Together -->
<Image
    Grid.Column="2"
    Width="325"
    Height="244"
    Source="Resources/summer_325x244.jpg"
>
    <Image.Effect>
        <bme:PhoenixEffect>
            <bme:PhoenixEffect.BInput>
                <ImageBrush ImageSource="Resources/fall_325x244.jpg"/>
            </bme:PhoenixEffect.BInput>
        </bme:PhoenixEffect>
    </Image.Effect>
</Image>

The above is easy. As you can see, you just choose one of the images and set the blend mode effect on it. This actually causes that image to become the ‘A’ input (remember: A + B = R). Then, you simply set the ‘B’ input of the blend mode effect to the second image.

But it isn’t always that easy, is it?!

Many times when a designer is thinking of blend modes they aren’t thinking “Ok, I have two images and I want to blend those together.” They often are thinking, “I have this shape and I want to blend it into its background using a cool blend mode.”

Take a look at the following. Here I have a shape, a gray (#FF808080) ‘H’, on top of an image:

And, here I have the gray ‘H’, blended into its background image using the Color Burn blend mode:

Now, anywhere I move that ‘H’ … it is going to look different because it is being blended into its background, similar, of course, to making a shape transparent (although with different math).

So, how would I do this with the blend mode library that I’ve provided? Well, it would seem easy … and here is a valiant try:

<Grid Width="240" Height="150">
    <Grid.Resources>
        <SolidColorBrush x:Key="solidColorBrush" Color="#FF808080"/>
        <Path
            x:Key="path"
            Width="168.367"
            Height="152.44"
            HorizontalAlignment="Center"
            VerticalAlignment="Center"
            Stretch="Uniform"
            Data="(removed for clarity)"
            Fill="{DynamicResource solidColorBrush}"
        />
    </Grid.Resources>

    <Image
        Source="Resources/MSwanson - Wide - Water 06.jpg"
        Stretch="Uniform"
    >
        <Image.Effect>
            <bme:ColorBurnEffect>
                <bme:ColorBurnEffect.BInput>
                    <VisualBrush Visual="{StaticResource path}"/>
                </bme:ColorBurnEffect.BInput>
            </bme:ColorBurnEffect>
        </Image.Effect>
    </Image>
</Grid>

In the above, I am using the Image as the ‘A’ input and then passing the shape (Path) in as a VisualBrush for the ‘B’ input on the color burn blend mode effect. Here is what happens, though:

What is going on? Well, if you recall from Greg Schlecter’s series (1 and 2) on multi-input pixel shader effects (which is how the blend modes are implemented), the inputs have to be either a VisualBrush or an ImageBrush and the inputs have to be the same size. If they are not, the second input is resized to match the first input.

So, our ‘H’ path is getting sized bigger to match the image’s size and the parts outside of the path are taking part in the blending that is occurring (i.e. the dark areas outside the ‘H’) as well.

Greg Schlecter suggests (in the aforementioned articles) how you can solve the ‘resizing’ issue … by using the Viewbox property on the brush.

But, let’s take a step back here. Do we really want to apply the blend mode effect to the background? No, we don’t, as that would limit us to having only one effect per background. For that matter, it is also not very intuitive as you typically think of blending the shape into the background which suggests that it makes more sense to apply effect to the shape.

While thinking about how to solve this problem, I ran into this WPF forum post. I first thought, “Oh, no! I’m up a creek without a paddle.” But, then I dove in on Jeremiah Morrill’s GlassBehavior … and got it too work (at least for certain situations)!

(I’m not going to cover behaviors in this blog post, but they are basically something new with Expression Blend 3.x. They are an implementation of the attached property behavior pattern and allow the designer inside of Blend to drag and drop behaviors onto elements in the element tree. See here and here for more info.)

Jeremiah’s GlassBehavior is a behavior that let’s you apply an effect to the background underneath the element that you are attaching the behavior to. He uses it to apply a SmoothMagnifyEffect (to get a glass like appearance) … but you can really use it to apply any effect. And that is just what I did.

Take a look at this xaml:

<Grid>
    <Grid x:Name="grid">
        <Image
            x:Name="image"
            Source="Resources/MSwanson - Wide - Water 06.jpg"
            Stretch="Uniform"
        />
    </Grid>
    <Canvas Width="168.367" Height="152.44">
        <Path
            Width="168.367"
            Height="152.44"
            Stretch="Uniform"
            Data="(removed for clarity)"
            Fill="{StaticResource solidColorBrush}"
        >
            <i:Interaction.Behaviors>
                <local:BackgroundEffectBehavior
                    Visual="{Binding ElementName=grid, Mode=OneWay}"
                >
                    <local:BackgroundEffectBehavior.Effect>
                        <bme:ColorBurnEffect>
                            <bme:ColorBurnEffect.BInput>
                                <ImageBrush>
                                <ImageBrush.ImageSource>
                                <DrawingImage>
                                <DrawingImage.Drawing>

                                <GeometryDrawing
                                    Brush="{StaticResource solidColorBrush}"
                                >
                                    <GeometryDrawing.Geometry>
                                        <RectangleGeometry Rect="0,0,1,1"/>
                                    </GeometryDrawing.Geometry>
                                </GeometryDrawing>

                                </DrawingImage.Drawing>
                                </DrawingImage>
                                </ImageBrush.ImageSource>
                                </ImageBrush>
                            </bme:ColorBurnEffect.BInput>
                        </bme:ColorBurnEffect>
                    </local:BackgroundEffectBehavior.Effect>
                </local:BackgroundEffectBehavior>
            </i:Interaction.Behaviors>
        </Path>
    </Canvas>
</Grid>

First of all, notice how the BackgroundEffectBehavior attaches to the Path through the attached property collection i:Interaction.Behaviors. This is how the behavior hooks its functionality into Path.

The BackgroundEffectBehavior’s Visual is set to the background (the grid which is holding the image) … and the BackgroundEffectBehavior’s Effect is set to the ColorBurnEffect which has a SolidColorBrush as its ‘B’ input. I also have the same SolidColorBrush set as the Fill of the Path … but this is just so that I can see it in the designer … as at runtime … this behavior kicks in and that Fill is not used.

This is what we get from the xaml above … but basically … success!

Now, a few caveats. This whole thing seems to be very fragile.

For example, in order to get this to work, I had to put the image inside the grid … as a sibling to the Canvas that contains the ‘H’ path. Certain other ways of doing it didn’t work. For example, if I set the BackgroundEffectBehavior’s Visual to the grid which contains both the grid/image and the ‘H’ path … it doesn’t work.

Also, if you change the StaticResource(s) to DynamicResource(s) … it doesn’t work.

Another issue is that using this behavior inside of Blend … does not result in what-you-see-is-what-you-get (WYSIWYG) blending. That is why I also set the Fill of the Path above to the same SolidColorBrush that I used as my ‘B’ input to the color burn blend mode effect. In that way, at least, I can see the ‘H’ inside of Blend.

Finally, I have not done any performance analysis (yet) of this, but the BackgroundEffectBehavior uses two VisualBrush(es) to get its job done. So, if you use a lot of these, I wouldn’t be surprised if it starts slowing stuff down.

The best solution here, is really for Microsoft to bake blend modes into the platform. Unfortunately, blend modes will not be in next release of WPF (.NET 4.x) … but the good news is that Brendan Clark from Microsoft says he’s pushing for it.

Here is the code. Unfortunately, the BackgroundEffectBehavior is WPF-only right now (I hope to fix this), but I have updated the Silverlight test harness to have the gradient and image test harnesses. Enjoy!

Here is a live Silverlight 3 test harness (you will need the Silverlight 3.0 runtime, 3.0.40624).

p.s. I just want to give a shout-out to Mike Swanson and his wallpaper images. They rock. Period. The water droplet background I am using above is one of his.

Share/Save