We have decided to move on with trying to use XAML in Codejock. Instead, we are using SVG via Direct2D which has APIs that lets one render SVG to a bitmap. D2D supports more SVG than CJ supports XAML. The main limitation we have found is referenced styles. So, we just embed the style into each SVG element.

So far our results are pretty good and there are a lot more tools that create SVG than create Silverlight XAML which is a Microsoft format created long, long ago in an OS far, far away. I think I saw a Microsoft note saying Silverlight XAML is end of life and its time to move on.

When we load our SVG images, we know what the size of the images we want and we render to a bitmap. We render and then give the image manager the bitmap. This also means that the normal CodeJock code that automatically creates the disabled image works. Also, we use HTML tooltips and the Microsoft low level control that renders HTML supports SVG. We reference our SVG image for a command in the title/caption area of our tooltips.

The D2D functionality does depend on the version of Windows. One has to support NTDDI_WIN10_RS2. So, if you have to support Win10 build 1703, this SVG solution probably isn't an option. We have not flipped a switch yet to compile everything under RS2. We just push and pop a pragma in the one file that uses the D2D SVG APIs we use to render our images. Microsoft will be phasing Win 10 out. I think around this time next year. So, the version, at leas for us, will be a non-issue once we update all our projects.

Also, I presume that Microsoft will continue to enhance their D2D support of SVG as it is an open standard. See, ID2DRendterTarget and ID2D1DeviceRContext5. It was not much code for our display guru to implement SVG using Windows Imaging Component and D2D.

As usualy your post is quite detailed and immensely useful. I tried ShapeConverter yesterday and found that GeometryDrawing and other elements you mentioned that I had not yet encountered and tried were indeed DOA in CodeJock. I have asked our UI team to read your reply as you have added a lot of good tips on how to approach using CodeJock xaml.

I sure hope CodeJock is actively working on improving xaml support. Too bad they have focused on Silverlight which is quite "old" and, as Microsoft has indicated, passe.

Hi rdhd.

The reason for doing 16px and 32px vector icons is for style mainly. If you have a 1px stroke at 16px, but you rasterize that at 32px, that stroke will come out 2px thick. Our icon style is similar to Office and Axialis 2019 (Axialis' XAML tends to work good in XTP by the way). So we want 1px strokes at 16px and at 32px. And we also have slightly different proportions and padding for small 16px vector icons versus large 32px vector icons.

If it works for you, you can maybe get away with a single size. You may have to use <Viewbox> tags to get the XAML to rasterize at variable sizes. But that can ruin your pixel alignment and make your icons look blurry. That being said so will non-integer DPI scaling. I'd be careful with it. Give this article from Axialis a look:

I have had similar issues with XTP XAML as what your having. When we first started to do vector icons InkScape was the first thing we tried. It does spit out stuff that XTP doesn't like. The XAML support in XTP is only a subset of whatever XAML elements Silverlight, WPF and so on have available. So you got to be a bit careful and stick with the basics. The MarkupPad utility is useful for testing this stuff. Here is what I know isn't supported:

Additionally I know that the following are interpreted as integers instead of floating point:

But these are rarely too much of an issue, especially if you are pixel aligned.

We are still using the XAML export plugin for Adobe Illustrator and exporting with "XAML for Silverlight". And that works most of the time for us. There are a few weird things with that plugin. Like having to put a transparent rectangle that covers the entire canvas to ensure the output XAML canvas size is the entire canvas (otherwise it clamps down to the content). But it mostly gets the job done. But gradients are not something that tends to work I think. We had one or two icons trying to do it we had to rework to not include a gradient.

Another idea I was contemplating trying, but never got around to trying, was having a pre-compile step that goes over the icon SVG or XAML vector icon resources and rasterizes them with an external library, like maybe nanosvg for svg or .NET for xaml, to appropriately sized bitmaps. Alternatively this could be done at runtime for the current DPI awareness and then cached. Then you can load those perfectly sized bitmaps right into the XTP image manager and side-step the XTP XAML entirely. But who knows if this is a good idea or not in practice.

Hope that helps :)

I was reading your post as I am trying to figure out how this xaml stuff works. 

Out UI team wants to create a single vector icon for each ribbon control or backstage button (ignoring disabled for now) that will work for any user DPI setting. So I ask why are you creating two sizes? 

I think our UI team is aiming to create 32x32 (pixel) sizes only. At least when I set the image size I am passing in 32 as the width. They are actually clamoring for SVG as our company has many products that use SVG and apparently their experience with SVG has led them to believe a single vector image should be sufficient. We are the only Windows desktop product in the company that uses CodeJock and they keep asking why we don't support SVG.

As an aside, so far, the UI team have not provided a single Silverlight xaml image that displays in CJ V 22.0. I can open them in Internet Explorer with no problem. They are currently trying Inkscape's latest version and using the save as Silverlight option. I have managed to get CJ to actually create a test image but only after I deleted the xaml <LinearGradientBrush.GradientStops> and <GradientStopCollection> the UI team is fond of. Either that stuff is not part of Silverlight or CJ just doesn't support those elements. CJ cannot create the runtime classes at which point CJ just gives up. Even after doing that and getting parse to succeed and an image icon to be available, I have stepped thru lots of code and see CJ using GDI+ to draw but nothing shows up.

I installed inkscape on my box and created the simplest image I could. I set the canvas size to 32x32 and placed an ellipse. After stepping thru the CJ parsing code, I found I had to delete <Canvas.Resources/> because it was empty and CJ didn't just ignore that, it gave up. I have asked the UI team to try an Adobe Illustrator add-in that I saw mentioned on the forums here so they can save their images as Silverlight xaml and hopefully it will work. I would note that I have no real ideal how to use Inkscape so I just hacked a bit to see what I could see.

My ellipse did finally display though it is quite a bit smaller than I expected. I'm guessing "px" does not stand for "pixel" but getting something to display is a start.

I can see this attempt to use xaml turning into a debugging nightmare :( Also, when searching around for Silverlight, I saw Microsoft saying it is at "end of life". All documenation I have scanned so far is related to WPF. I was searching for LinearGradientBrush and its MappingMode (CJ choked on the mapping mode too) and GradientStops to see if they are valid entities. I have asked the UI team to see if they can create gradients with no mapping mode and no <GradientStops> element.

Is this CodeJock compatible xaml creation as difficult to come to grips with as it appears so far? Our UI team has tried a number of times over the last year or two to give me xaml files that work in CJ. The only images I have gotten to work as we expect is xaml icons I have found in CJ itself. Well, and today, my tiny ellipse!

Yep. Opacity will fade them out but the hue remains. Just wondered if that was enough to indicate disabled. Of course some images can be grayscale themselves too.

If we end up supporting XAML, I'll be tempted to just change the CJ markup code if possible. I usually use the NTSC color to grayscale conversion method so its quite easy and fast. Better than SECAM which we always joked meant "Something essentially contradictory to the American method).

I did, and found the results unsatisfactory. I use a grayscale conversion function very similar to what Daniel shared in this thread, then also adjust the brightness a bit.

Opacity doesn't alter the colors, so it never actually looks "disabled" to me.

Hi rdhd.

The way I do it is have an archive of all of the .xaml files. I used to use .zip but found .tar.gz with libarchive to be much faster for this. I open this archive once on startup and read all of the .xaml out of it into strings. I then use CXTPImageManagerVectorImageHandle CreateMarkupHandle, actually I use my patched CreateDelayedMarkupHandle function I mentioned above. By the way that likely only helps if you have a very large number of icons to load. I'm loading around 1200, but each have small and large, normal and disabled. So its actually around 5000 icons being loaded.

I think using the IStream version of these should work fine if you want to read directly from a file stream. If you want to pre-process the .xaml though to do something like creating disabled variants it may be better to read the file into memory first, do what you want and then pass the string to CreateMarkupHandle.

I mentioned above I think, but I generate disabled icons at pre-compile time with a powershell script. For grayscaling I use the following function.

function Grayscale($brightnessFactor, [ref]$colour) {
    # Convert input colour to grayscale.
    $gray = $colour.Value.R * 0.299 + $colour.Value.G * 0.587 + $colour.Value.B * 0.114
    # Scale by brightness factor.
    $gray = [System.Math]::Pow(($gray / 255), $brightnessFactor) * 255
    $gray = [System.Convert]::ToInt32($gray) # Floor
    $colour.Value = [System.Drawing.Color]::FromArgb($colour.Value.A, $gray, $gray, $gray)
}

Shouldn't be too hard to do the same thing in C++. For light themes I use a brightness factor of 0.5, for dark themes I use a brightness factor of 1.25.

By the way. The names of my icons are actually the id names of the command. e.g. ID_FILE_NEW.xaml. I have a pre-compile awk script that parses CommandsRes.h into a header file that contains the id name strings and id number paired together. That way we can map the file name to the id of the command at runtime.

Regards,

Daniel.

Hi markr,

I was thinking that if we add support for xaml icons, I would want to load from files or resources. Not because of a performance issue but because it can be more dynamic. Image creation people can just drop a file on disk and cause a load or reload to occur in our app and they can view the results right away. No coding needed, no build or waiting for a build to deploy. I do this for BMP and PNG now and the image creator just has to go to our options dialog and change color theme (I support images on a per color theme basis too). I discover the ID of the resource by using a naming convention that has the ID included in the name. Filenames have the ID and when adding a resource using Visual Studio, one just goes to the properties window and selects the auto-generated ID and types something like (quotes included) "image12345_16". The "16" is irrelevant to my code as I just care what is between "image" and "_". Filenames follow the same pattern - image12345_16.png, image12345_32.png ...

I also auto-scale images using WIC for cases where a user is running at a high DPI like 200% on a 4k monitor. If any scaled image looks bad, our team just creates, say a 64x64 version of an image and drops it on disk (image12345_64.png), or adds it to the resource DLL and forces the reload.

I haven't tried using XTPCreateReadOnlyFileStream yet to see if that's the way to load a XAML icon from disk but it appears that it should work.

As for dimming, I don't supposed you tried setting an opacity to some low value like 0.3? I've been playing around with that and it shows promise. Images "fade" out quite well - so far. Ok, so I only have one simple image taken from the CommandBarIcons sample so its very simple ...

I load XAML icons "on demand" (during containing window construction) from program resources and haven't observed much of a delay at all.

My approach is to parse the icon XAML and replace all instances of "fill" and "stroke" attributes with dimmed versions of the target colors. For the dimming, I first convert the color to grayscale and then "lighten" it by 50%. The resulting disabled XAML images are then cached in an XTP image manager instance.

Just wanted to share what's been working well for me in case it helps.

- Mark