design FireMonkey User Interface VCL

FireMonkey vs. VCL

Frequently when I am talking about the VCL or FireMonkey I get some of these common questions:

  • Is VCL deprecated?
  • Which is better FMX or VCL?
  • If I am starting a new app today, should I use VCL or FMX?

FireMonkey vs. VCL

The first is easy to answer, the other two are a little harder. The VCL (or Visual Component Library) is NOT depreciated, nor will it be any time soon. As long as there is Windows and the Windows API, there will be VCL. Just recently in Marco’s Windows 10 Webinar he said “VCL is the best library for Windows desktop development and fully embraces Windows 10.

The VCL gets new components, features and bug fixes frequently, but maybe not as often as FireMonkey. The reason is the VCL is a mature framework, while FireMonkey has been going through a lot of growth the past few versions (although it has stabilized a lot recently, and is reaching a more mature status.)

So which is better, and which to use? There isn’t a straightforward answer, but instead I can tell you the advantages of each, and you can make an educated choice for your next project.

Visual Component Library (VCL)Visual Component Library (VCL)

The VCL was release with the first version of Delphi. It is mostly a thin wrapper over the Windows API controls, but also includes a lot of owner draw controls. It uses GDI, Windows Handles and Windows Messages. This makes it subject to the same behavior as 90% of the other windows applications out there. If you want to you can inject a VCL button from your app into another app, or sniff messages sent to a different app and redirect them into yours.

As I said earlier, the VCL is mature, and so is the 3rd party component space. There are thousands of high quality VCL components, controls and libraries out there. Probably the most notable are the grids. The VCL grids are the best in the industry, and for good reason, our technology partners were making grids for the VCL before any other platforms had the idea of 3rd party controls. So if you want the best grid on the planet, you will probably use the VCL (although the FireMonkey grids are gaining fast).

Because VCL is mostly a thin wrapper on the Windows API, VCL based applications are much smaller than FireMonkey applications. Anymore this usually isn’t a huge deal with fast download speeds and huge hard drive sizes. But if you need a really small lightweight application, then VCL might be a good choice.

Because VCL has been around a while, you may have some existing VCL code that you want to integrate into your application. You could use a utility like Mida converter to convert it to FireMonkey, or something like Monkey Mixer or TFireMonkeyContainer to mix FireMonkey with VCL.

Generally if I am building a simple grid intensive application that I know will only run on Windows, then I find myself using VCL. Or if I need to leverage a specific 3rd party control, or Windows API feature that requires Windows messages. This is less and less frequent though.

FireMonkey (FMX)FireMonkey Cross Platform Framework (FMX)

As FireMonkey is a newer framework you tend to see it covered more. A lot of people are still learning how to use it, and how to tackle cross platform development. The main advantage of FMX is that it is designed from the ground up to be a cross platform framework. It lets you design a single user interface that runs and looks great on Windows, iOS, macOS and Android. But that isn’t the only reason to use FireMonkey.

FireMonkey is based on the latest GPU frameworks: DirectX for Windows and OpenGL elsewhere. It supports both 3D and 2D rendering models, both of which are hardware accelerated. If you want to have some powerful graphic effects or 3D, then FireMonkey is probably going be your first choice. There are some really powerful 3D engines as well as some great graphics effects libraries for VCL, but FireMonkey has these ideas baked into it’s core.

FireMonkey is also a lot more flexible. You can embed any control in any other control with FireMonkey. This ability to build composite controls turns the smaller set of controls it includes into a much more robust set of controls. Also there are animations and effects that let you build fantastic, rich user interfaces with very little effort.

VCL has a respectable set of containers and alignments, but FireMonkey has many, many more, and again they are much more flexible. Another big difference is FireMonkey uses a single precision floating point number instead of an integer in laying out the controls. Much higher precision, but typically subpixel precision doesn’t buy you much. Where it does make a difference is when you scale on FireMonkey since it supports multiple pixel densities.

The most obvious reason to use FireMonkey is if you are currently planning to target multiplatform, or there is a possibility you might in the future (which is a pretty high likelihood). The other reasons are you want a more flexible UI or you plan to take advantage of 3D or other effects FireMonkey provides.


In summary VCL is amazing, and continues to get fixes and new features. It is a better user interface framework than any other out there, except maybe FireMonkey. So use VCL when you are only targeting Windows and don’t need the 3D, effects or flexibility of FireMonkey. Use FireMonkey when you are going multiplatform, or you new some of FireMonkey’s flexibility especially when working around graphics.

Both frameworks will be around for a while. As you use them both you will get a better feel for which to use in each situation. I’d love to hear your feedback about when you choose which framework.

9 replies on “FireMonkey vs. VCL”

Can we have FMX also use OpenGL on Windows and be interoppable with plain OpenGL? I have an app that heavily depends on OpenGL but just couldn’t benefit from the new Delphi cross-platform ability (because if we use Delphi for cross-platform we need to use FMX).

>Jim McKeeth says:I know some people have built cross platform OpenGL support.

The closest I can find is the CubeMan demo by Paul Toth:
However, this is almost like using FreePascal without using Delphi’s own UI framework.

Also, Eric Grange once said (
> Given that FMX uses OpenGL on iOS& OSX, it should be possible to hack
> the FMX rendering context to have GLScene render there, but that would
> involve hacking (that might be broken by each FMX update), as FMX isn’t
> facilitating that.

So, Jim, what is that cross platform OpenGL support that you know of?

Currently there is no official support for OpenGL as a target for FMX on Windows platforms.
I did hear rumor of a hack to do it once, but unfortunately I have never tracked down the actual hack to try it.

One solution would be to circumvent FMX altogether and provide your own library for access to the underlying API’s. I have spent considerable time working on this approach, and can tell you from the benefit of my experience that you’re likely far better off working within FMX than attempting this.

To explain why, consider this:

Under FMX, the only real incompatibility between the platforms are shaders. You must provide both GLSL and HLSL shaders for FMX to function across multiple platforms. Otherwise, just using it’s 3D classes is sufficient for the vast majority of rendering tasks, and since about the Seattle release the problem of over-using the PCI bus appears to be resolved too.

The alternative, circumventing FMX, involves creating a bare bones application for Android, iOS, Mac and Windows. My own efforts included a linux port in preparation for the coming Linux support in RAD.

What I found was that the OpenGL implementation is quite different across all of these platforms, context creation differs, functions to select the current context are different, the functions to swap back buffers are different…

Once you get over all of that and have a working context on all platforms, you discover that OSX does not support OpenGL contexts newer than version 2.1 unless you install a third party X server (thanks Apple!). Which means that on Windows or Linux you can have a 3.3+ forward compatible context right up to the latest version, on Mac a 2.1 context, and on Android and iOS an OpenGL-ES context of 2.0 (if you’re lucky depending on the device and SDK 3.0). That leaves you with at least three different versions of GLSL to write shaders for, and you’re right back where you started with FMX, but still don’t have a rendering pipeline, geometry classes, a scene-graph and so on.

Though it may feel uncomfortable to do initially, using FMX to abstract DirectX / OpenGL / ES really is the path of least resistance.

As a side note, my own efforts were based on a simple 3D game engine that I wrote many years ago for fun. I tried to port it to Delphi for the ease of deployment offered by RAD Studio, and spent considerable time doing so. While I’m not able to share it with you at this time, I may be prepared to release it at some point in the future. It would be in binary form but available free at least for the first version. I’ll re-post here if the project makes it that far.

Craig, thanks a lot for your effort and sharing your insight. I’m still not inclined to using FMX for my project for a few reasons: 1. I’ve heard of low performance of FMX and I’m still not sure if it’s really on par with what I can get from GLScene (my project is a real-time GPU-based application so performance is important). 2. I already invested a lot basing my work on OpenGL/GLScene and rewriting everything I need in FMX seems a daunting task.

I’ve heard that the reason behind FMX choosing DX over OGL on Windows is for better performance. I’ve also heard people didn’t really find FMX performing too well even on DX. DX seems a step backward for cross-compatibility to me.

While it is great to be able to have programs running on all desktop/mobile devices, there’re still cases where we need to limit ourselves to desktop-class hardware support. One example is Adobe Photoshop – their Windows and MacOS versions share the same code base, and their Photoshop Express for mobile devices is actually a completely different program that has to be built differently anyway.

If Embarcadero could just allow OpenGL to interop with FMX – we could then keep using OGL 2.1 to do both Windows and MacOS – which is already a huge market. In my own experience, due to the vast variety of GPUs out there, we at first kept the OpenGL version we use down to 3, and then for even better compatibility, 2.1. And for OpenGL, we already have GLScene covering us with scene graph, etc.

I’d agree that there were some performance issues in FMX previous versions, correctly used those issues are no longer present. The problem stemmed from Embarcadero doing something that their customers asked for, render FMX applications to a bitmap and then pipe that bitmap to the GPU, in order to solve some ‘pixel-perfect’ alignment issues (as you know OpenGL doesn’t really have the concept of pixels in the traditional sense).

DirectX support on windows was never about performance, it was about availability. RadStudio was aimed predominantly at line-of-business users for the longest time, and these users rarely install up to date OpenGL drivers on their systems. Direct3D is always present and up to date thanks to MS Update.

You’re not the first to request OpenGL backed FMX on windows, I’ll forward the request along. I personally would love to see a new project template named “OpenGL Application” which provides the relevant context on all supported targets, but sadly, it’s not my decision to make.

Comments are closed.