The Internal Rendering Engine Is Now the Default in GemBox .NET Libraries

We have released a new version of the GemBox .NET libraries that makes the internal rendering engine the default in GemBox.Document, GemBox.Presentation, GemBox.Pdf, and GemBox.Spreadsheet on all supported platforms.

The internal rendering engine has existed in the libraries for some time, but starting from this version, it is used as the default everywhere. No code changes are required: existing applications can continue to use the libraries without modification.

Until now, rendering on Windows relied on the WPF rendering engine, while rendering on Linux relied on the SkiaSharp rendering engine. In contrast, the new engine is written entirely in managed code and ships directly with the libraries, so it runs on Windows, Linux, containerized environments such as Docker, and mobile platforms without any additional libraries.

Consistent output on all platforms

The same engine now renders documents on every platform, so a document rendered on your Windows development machine produces consistent output when the same code runs in a Linux Docker container or on a mobile platform. This means you no longer need to test rendering on every platform separately, or worry about platform-specific output differences.

Reduced memory usage

It uses considerably less memory than the previous engines. This matters most on servers, where documents are converted continuously or in parallel. It also helps containers and mobile platforms, where available memory is limited. With the lower memory cost per document, these memory-constrained targets can process more documents with the same footprint, or free up space for other work.

No more platform-specific engine issues

The previous defaults came with problems of their own. The WPF-based engine on Windows had issues related to the WPF Dispatcher, which complicated the use of rendering in multithreaded code. The SkiaSharp-based engine on Linux required platform-specific native libraries to be installed, and missing or mismatched native libraries often caused deployment problems. The new default is fully managed and has no dependencies on native libraries.

If you have any questions, complaints, or suggestions, feel free to contact us. If the new default behaves differently in your environment, or if you run into problems after upgrading, let us know.