Skia4Delphi: Google's Skia graphics for Delphi

One graphics engine for every Delphi target

Skia4Delphi is described as a cross-platform 2D graphics API for Delphi platforms based on the Skia graphics library from Google, providing a comprehensive 2D API usable across mobile, server and desktop applications to render images.

The way it is used is worth understanding early, because it is not a library you call in place of a canvas. The README describes it as providing a comprehensive 2D API that can be used across mobile, server and desktop models to render images, and the installation instructions end with a step that says to right click in your application project and click Enable Skia.

That is the key idea. Skia4Delphi can be used in three ways: as a direct API for drawing, as a set of replacement controls for the visual component library, and as a replacement for the FireMonkey graphics engine so that an application you already have draws through Skia without being rewritten.

The project works on the Delphi side of the ecosystem as well, with console applications, FireMonkey and the visual component library all supported, and it runs on Windows, Android, iOS and macOS.

The project is MIT licensed and the current release is 7.3.0.

What Skia itself brings

The About section of the README makes the case for the underlying library, and it is worth repeating because it explains the choice.

Skia is described as an exceptional open-source library dedicated to rendering 2D text, geometries and images, with a focus on precision, superior quality and high performance, offering versatile APIs compatible with a wide range of hardware and software platforms.

The list of products that use it as their graphics engine is the strongest part of the argument. Google's Skia is the engine behind Chrome, Chrome OS, Android, Flutter, Xamarin, Mozilla Firefox and Firefox OS.

That list explains the practical consequence for a Delphi developer. The rendering you get is the rendering a large number of widely used applications get, which means text layout, emoji handling, dash strokes and image scaling behave the way a web user expects, which is a different standard from what a native mobile toolkit of the same era typically delivered.

It also explains why the FireMonkey replacement is the headline feature rather than a curiosity. FireMonkey has its own canvas, and it draws differently from Chrome on the same device.

The feature list

The features are listed as a flat catalogue, and the order roughly follows the layers of a graphics stack.

At the base is the canvas 2D API and text layout, with CPU software rasterisation and GPU accelerated rendering as two ways to execute the same drawing calls. Right-to-left rendering is there, which matters for the international applications that are a large part of the FireMonkey audience.

Above that sit the document level formats, with SVG rendering and creation and PDF output. Then the shader and effect machinery: runtime effects, a shading language, and shaders with mask and colour filters. Image and path effects follow, and then an animated image player covering Lottie, GIF and WebP.

Finally, the image codecs, listed as bmp, gif, ico, jpg, png, wbmp, webp and raw images, with a note that there is much more.

Two of those entries are unusual for a Delphi binding. A shading language and runtime effects mean you can write your own GPU shader pipeline, which is not something the standard FireMonkey or visual component library canvas offers. And the animated image player with Lottie support means you can use the animation format that designers already export from the web design tools, which removes a real conversion step from a design workflow.

The PDF output is the other one to note, since generating a PDF from a drawing surface, rather than from a document model, is what you want for a report or an export.

Installing and enabling it

There are three installation routes, and the README recommends the first.

The recommended one is the setup: download the setup of the latest release and install it.

The second is Embarcadero's own package manager inside RAD Studio, under the tools menu as the GetIt Package Manager, which is the route that fits a team already managing dependencies that way.

The third is the Chocolatey package manager.

  choco install skia4delphi

Two remarks follow. Manual installation is possible although not recommended, with the details in the installation document. And the pre-built Skia binaries were included in the source, but you can easily recompile them, with the build document explaining how.

That second remark is the interesting one for anyone worried about long term maintenance. Skia4Delphi does not just ship a Pascal wrapper, it ships the Skia binaries themselves, which means the package works without you having to obtain and build Skia separately. The trade is size and the fact that you are taking a specific Skia build rather than tracking upstream.

After installation, enabling it in a project is a context menu action: right click in the application project and choose Enable Skia. The tip underneath says that to improve the quality and performance of FireMonkey drawings, the replacement of the FireMonkey graphics engine with the Skia4Delphi render is automatically enabled.

Replacing the FireMonkey renderer

This is the feature the README leads with among the capabilities, and the claims are specific enough to check.

Using the library it is possible to override FireMonkey's graphic engine so that it can use Skia as its default canvas. The README then lists what your FireMonkey application will automatically do once that is in place.

It draws with antialiasing on any platform, with the drawing quality based on the Form.Quality property, which means the existing quality switch in your forms starts to mean something new. It increases the overall graphics performance of the application by up to fifty percent, even drawing with higher quality. It resizes images with better quality, also based on that property. It supports right-to-left text rendering. And it fixes dozens of inconsistencies in drawings, especially in corners and strokes such as dashes, and in texts with special emoji.

The performance claim is the one to treat carefully. Fifty percent is a best case figure for a drawing-heavy application, and the interaction with quality settings means the comparison depends on what your quality property was set to before. If you were previously drawing without antialiasing and now draw with it, you are doing more work per frame and the win comes from elsewhere.

The list of consistency fixes is the more reliable benefit. Corner rendering, dashed strokes and emoji are exactly the places where a native toolkit and a browser engine disagree, and they are the places users notice.

The controls and the SVG caveats

The README lists replacement controls for both visual component library and FireMonkey applications, and they are named after the platform control they stand in for.

There is an animated image control, a label control, a paint box control and an SVG control. The animated image control is the one that ties back to the Lottie, GIF and WebP support in the feature list, and the label control is where right-to-left text and custom fonts land, with a separate section on custom fonts and another on right-to-left handling.

The SVG control comes with a documented limitations page, which is a good sign. A binding that provides SVG rendering and creation will not match every renderer, and a project that says so is more useful than one that does not.

The README also has a benchmark section, which is what you would want before believing the performance claims, and a showcases section for real applications built with the library.

The samples directory in the repository matches that: a demo project, a webinar demo, a webinar game and a conference sample from 2022 with a shader button, which tells you that the interesting use case for the library is custom shaders on buttons rather than merely drawing text.

There is a dedicated section on using the library in console applications as well as the graphical ones, and the shared example code shows the pattern, creating a raster surface, clearing it, drawing through a callback and encoding the result to a PNG file.

Repository layout, releases and what to check

The repository layout is that of a binding project with binaries attached.

There is a Binary directory for the pre-built Skia libraries, an Externals directory for the dependencies, a Source directory for the Pascal code, and a Packages directory for the packages published to the component and package managers, which is what makes the GetIt and Chocolatey routes work. Samples, Tests, Tools, Benchmark and Documents fill out the rest, with an Assets directory holding the artwork, a validation file at the root, and a license file.

The build document referred to earlier lives in that documents directory, alongside the installation guide and the SVG limitations page.

On releases, the tags are 7.3.0 from 2026-08-17, 7.2.0 from 2026-08-03 and 7.1.0 from 2026-01-28, and the last push was on 2026-10-18. So this is a project on a steady minor version cadence, and the compatibility badge states Delphi XE7 and later support, with the cross-platform badge covering Windows, Android, iOS and macOS.

Three checks before you adopt it. Which Delphi versions your team can use, since the support starts at XE7 and the newest IDEs are the ones where the GetIt package manager exists. Whether you need the SVG path at all, and if so whether the documented limitations affect your artwork. And what the licensing looks like for Skia itself, which is separate from the MIT licence on this binding and is worth reading for a commercial product, particularly if you intend to redistribute the binaries.

Editorial conclusion

Skia4Delphi suits a Delphi team whose applications draw a lot of text, emoji, rounded corners or scaled images and want consistent output across Windows, Android, iOS and macOS, because binding Skia gives one rendering implementation everywhere and the FireMonkey replacement is a project setting rather than a rewrite. It is the wrong choice for a small application with simple graphics, since the native FireMonkey canvas is already adequate there, and the wrong choice if you need to stay inside the native toolkit for licensing or platform reasons. Verify first which Delphi versions you can use, since the support starts at a particular XE release, check the documented SVG limitations before you rely on SVG rendering, and run the included samples and benchmarks to see the difference on your own controls.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. skia4delphi/skia4delphi on GitHub