[Performance] Rewrite DirectWriteForwarder in C# to improve rendering performance

[deeprobin]

See #4768.

The current code is written in C++/CLI and I think that can be optimized. Unfortunately, I have written very little C++/CLI myself but I suspect that the generated IL code is smaller and better performing.

See also https://github.com/dotnet/wpf/tree/main/src/Microsoft.DotNet.Wpf/src/DirectWriteForwarder

[madewokherd]

Hi, I did this last year but I needed a small C component to get around some COM interop issues. https://github.com/madewokherd/wpf/blob/main/src/Microsoft.DotNet.Wpf/src/DirectWriteForwarder/CPP/DWriteWrapper/Factory.cs

[deeprobin]

@madewokherd Oh cool 👍🏼 Is in this already in Pull Request?

[madewokherd]

No, I did it because I needed a way to build it on Linux using open source tools for wine-mono. I didn't expect it to be useful for upstream.

It probably needs to be cleaned up. The few C functions needed could be moved to an existing dll, or maybe ComWrappers would remove the need for them. There's still TrueTypeSubsetter which I didn't touch at all, it doesn't seem to be commonly used and could be moved to pure C++ I think. And the C# code probably shouldn't be mixed in with existing C++ code.

It also needs build system updates as I just used my own build system (my requirements were to build on Linux with Framework Mono, so the existing build files were not usable for my purposes).

I'm skeptical that this will improve performance. We still have to call into dwrite.dll so the native interop is just done in a different place.

Maybe I can at least put something together so you can do performance testing, once I find some free time.

[ThomasGoulet73]

Hey, this is a great idea and I've actually been working in my free time on converting DirectWriteForwarder to C# for the past couple of weeks. The performance from the move from C++/CLI shouldn't be that noticeable since, as @madewokherd stated, we're still calling into dwrite.dll. But, there are other advantages, here are some in no particular order:

• Trimming support. The .Net Trimmer does not support C++/CLI assembly analysis so it might remove code that is used in DirectWriteForwarder which can produce exceptions that are hard to diagnose (Eg. .net 5 trimming causes crash on copying text #3903).
• NativeAOT support. NativeAOT does not support C++/CLI assemblies at all, and if I remember correctly, the team responsible for NativeAOT does not plan on adding support for it. (COM interop support runtimelab#306)
• Crossgen support (This one I'm not 100% sure). I think Crossgen does not support C++/CLI assemblies so we may be leaving performance on the table here.
• Ease of development. I think most people in the community that would like to contribute on WPF are better in C# than C++ because I think they all used C# and/or WPF before wanting to contribute here (I might be totally wrong and this statement is not in any way data-driven). Also, most of the code in WPF is already in C# so this would be good. The ease of development might also help optimizing the C# code after the port.
• It's a legacy technology (I think, I wasn't able to find an official statement but I remember reading it somewhere).
• Probably others that I couldn't think of off the top of my head.

For now, the prototype that I'm working on is not open source because it's not working yet, but I'm making progress. I took a slightly different approach than @madewokherd, I use structs for DWrite objects that I wrap in a CriticalHandle so the lifetime management is done by the GC and we almost never have to manually release them. We don't really need ComWrapper because if I recall correctly, DWrite is not "true COM". Most of DWrite objects are created by there parent object and one-way only (DWrite -> Managed).

Keep in mind that what I said might be totally untrue but for now, what I've done seems to be working.

We would also need confirmation from someone in the WPF team that they would be interested in a community PR for this, because if it's not built-in, the usefulness would be really limited.

Thanks!

[madewokherd]

Apparently the part I had trouble with was implementing the IDWriteFontCollectionLoader and IDWriteFontFileLoader interfaces on the C# side. We would sometimes get calls to these interfaces after calling the corresponding IDWriteFactory::Unregister* method.

I don't remember exactly why that was a problem, but I was convinced at the time that I couldn't fix it while using builtin COM support to implement the interface, and I didn't want to rewrite it based on delegates.

Incidentally, that's the sort of reference cycle involving unmanaged objects that I don't think the GC will be able to detect for you.

[ThomasGoulet73]

I didn't hit this yet so maybe my app doesn't go far enough or it's something specific to built-in COM. I'll look into it once I hit this but thanks for the info!

My current plan for the port is this:

1. Remove reference to DirectWriteForwarder in PresentationCore.
2. Add every class that existed DirectWriteForwarder and that are required by PresentationCore.
3. Implement every required method as throw NotImplementedException.
4. Start a demo app using the built assemblies and wait for NotImplementedException.
5. Port the method from C++/CLI to C#.
6. Start again from 4.

I'm currently doing steps 4 to 6. This might not be the most efficient way but I wanted to do it small steps at a time to make sure that every method works and that it doesn't start breaking everywhere. This is a direct port so there are no changes other than porting C++/CLI code to C#.

[deeprobin]

@ThomasGoulet73
Thank you for taking a look at this. If you need some assistance, I can help you 😄.

[deeprobin]

I have created a benchmark for DWrite in general. This benchmark covers the direct call of the methods via COM.
The COM overhead cannot be read out here, of course, but perhaps it would be a future consideration to no longer use DWrite but to rewrite the complete font rendering in C#.

Benchmark on AMD Ryzen 5 3600 (6-Core): https://files.deeprobin.de/dwrite-bench/report/
Source Code: https://github.com/deeprobin/dwrite-benchmark

@ThomasGoulet73 But of course the first step is to get rid of the C++/CLI code.

[ThomasGoulet73]

I have some updates, I ported a good chunk of C++/CLI code to C#, enough to run a simple app without needing any C++/CLI code. I'll start cleaning my port and I will push it to my fork when it's in a "good enough" state. There's still a large task of testing everything but from my initial testing, it seems to work.

One nice thing that I noticed is that I was now able to trim a simple WPF app with few or no linker hints/configurations.

[deeprobin]

@ThomasGoulet73 Oh thats nice. Thanks for the time you put into this.

[ThomasGoulet73]

I pushed my changes to a branch in my fork https://github.com/ThomasGoulet73/wpf/tree/managed-dwrite for those of you who want to try it. There are few methods that are still not implemented because I didn't hit them yet.

My next step is to do some testing using WPF samples and then try to split this branch in multiple PRs to try and merge it progressively.

[deeprobin]

I pushed my changes to a branch in my fork https://github.com/ThomasGoulet73/wpf/tree/managed-dwrite for those of you who want to try it. There are few methods that are still not implemented because I didn't hit them yet.

My next step is to do some testing using WPF samples and then try to split this branch in multiple PRs to try and merge it progressively.

Oh that seems great. Good work!

A small thing, besides the unimplemented methods: Couldn't this theoretically be converted to a struct that doesn't use an object but an int (the only constructor call of Span is an int and by using int it is not boxed). This would allow the compiler to allocate the span on the stack.
Since I don't know all the background, feel free to be critical :).
Code Snippet / Span