Disabling Vector

I am trying to understand if there any better way to handle this. Loading file and changing its attributes programmatically is the best logic I could come across. 

More icons = better software 

There are benefits but also downsides. A benefit being avoiding have to add resource ids and so on for each icon, icon size and icon state. It is more work to setup loading from an external source. You have to map those to command ids at some point. We do have a resource DLL of course full of all the usual stuff, just not our icons. I doubt there is a big performance difference one way or the other. If I had to guess resources would be faster. Recently I found for this use case that .tar.gz is a fair bit faster than .zip with similar compression so switched to that.

As for vector icon loading it self. I too found that the performance of that can be a problem. We added around 4 seconds to our loading time when we moved to using vector icons. Not to mention around ~400mb more initial memory usage. We do have quite a lot of icons so are probably an outlier. Around 1200 icons total, each with a small and large, and with a normal and disabled state. So that makes around 5000 icon handles to load. Loading all that markup takes a lot of time.

You can save a little bit of time by minifying your XAML at pre-compile time but that'll only get you so far.

One thing I tested out was loading these on a worker thread but this stuff is just generally not thread safe. This is a bad idea.

Here is a patch someone might find interesting...

CXTPImageManagerVectorImageHandles actually already keep a copy of the XAML in their serialization data buffer. Piggy backing off of this we can delay building the markup UI element until we first try and draw the vector icon rather than immediately. If you have a ribbon like we do this means icons are built as they become visible when switching tabs. Building a tab worth of icons is quick enough its not noticeable. Similarly the disabled icon for things won't be built until they are needed. This took our loading time from 4 seconds to around 27ms and took our initial memory usage way down. That memory usage grows over time as icons are built on demand.

This delayed markup building idea can be used for markup list boxes as well by the way if you have a very large number of items to deal with. This only works for fixed height owner draw though since we can't measure the markup if it isn't built for variable height owner draw. The former is better for performance usually anyway.

Hi dbrookes,

Regarding my last question: XTPCreateReadOnlyFileStream perhaps? Looks promising.

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 ...

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.

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).

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 :)

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.