FireMonkey vs. VCL

I have finally started re-factoring hcOPF to support FireMonkey and Win64.  Win64 was a breeze, but supporting FMX is proving to be a bit of a challenge.

If I was EMB, I would be trying to make FireMonkey a write once compile on many platforms solution, and it is across Linux, Mac OS/X and Windows AFAIK, if you build an FMX application.  However, I would venture that most customers are looking to port their existing VCL codebase to access more markets, or at least leverage their existing knowledge, and might be a little hesitant to bet it all on a newly released UI framework sold and supported by a single vendor (especially after CLX).

All developers know, changing code tends to break what once worked, especially when you introduce more conditional compilation (check out my QC request 94287 to make conditional compilation easier to use).  To accomplish this end, the API usable to FireMonkey applications needs to have as much in common as possible with even VCL for Windows applications because at some point a developer will use code to manipulate the controls.  If it’s possible to use the same code for both platforms, you’ve saved in not having to maintain functionally duplicate code and in dealing with conditional compilation.

The ideal scenario would be to be able to specify either a FireMonkey or a VCL form DFM in a conditional directive, and have all the UI code shared (or minimal conditional compilation).  Of course, if you want to use the advanced functionality available in FireMonkey, perhaps this approach isn’t viable.  If you just want to target Mac OS/X without having to re-write your VCL application forms, and are using FMX for basic presentation of data, this would be ideal!  You wouldn’t have to invest the same effort to determine the merits of FireMonkey as a UI replacement for the VCL because you wouldn’t need to keep two separate UI source code trees in sync while FireMonkey matures.

So far, with my brief exposure to FireMonkey with XE2 I can see a number of problems in achieving the Write Once Compile for Many Platforms concept.  FireMonkey uses .Text instead of .Caption for some control window captions (ie: TGroupBox).  So while the control class may be the same, even some simple UI code cannot be shared with a VCL application.

Even non-visual code may be a challenge to re-use.  For instance, I use GetTickCount() to time activity in hcOPF.  I want to keep hcOPF compilable for users of D7 and above.  I personally feel that my coding productivity was higher in D7 with CodeRush than the Delphi XE with GExperts and CnPack.  Part of the reason for this is the code parsing the IDE performs in the main thread.  Type in Begin incorrectly, and you can be waiting for 10 seconds while the IDE tries to figure out what is going on.  That’s pretty sad on a 6 core system…but I digress.

GetTickCount() is implemented as an inline function in the implementation section in the System unit for MacOS and Linux, and the Windows implementation is in Windows.WinAPI.  Not a big deal to add a few {$ifdefs} to handle that, but GetTickCount() as defined in System is not accessible to other units.  So in order to use it, you will have to copy the implementation from System, and expose it.

From what I have seen of XE2 Update 4, FireMonkey is still not usable from a performance standpoint for replacing a normal VCL form. On my 6 core system with a Radeon 4250 the main form appears and you can visibly see the contents of the form background and content being rendered.  In this case, the form is just 4 edit controls in 2 separate group boxes using hcOPF Object Binding to populate the controls.

I think FireMonkey is a great concept, but adoption would be faster with an API more consistent with the VCL, and I think FMX has a long way to go before it becomes a viable replacement for the VCL and X platform Delphi becomes a true reality for more than the most trivial application written from the ground up for FireMonkey.

Tags: ,

9 Responses to “FireMonkey vs. VCL”

  1. Stefan Glienke Says:

    Performance of XE: I cannot share your experience but I don’t have cnPack installed (that thing caused more problems for me than it solved back in the days but that’s my personal opinion) but IDEFixPack and DDevExtensions from Andy. I think especially the IDEFixPack solves lots of performance issues in the IDE.

    API compatibility: I don’t know all the reasons behind certain incompatibilities but I think when you build a new framework it should not be made compatible at all costs. However FireMonkey got some of those bad design decisions in it anyway (I remember a post from Jolyon Smith about that).

    GUI framework and target platform: Don’t confuse these two. While the VCL is bound to Windows FireMonkey is not. So even when writing code for FireMonkey you still can make that platform dependent. Which leads to another thing…

    Separating GUI and business logic. Finally Delphi developers are getting into the trouble of mixing that. And the RAD approach of Delphi did it’s job encouraging people to put their business code into event handlers not thinking about what is presentation and what model.

  2. Chris Says:

    While I find certain small differences-for-differences-sake aggravating like you do, I disagree about making things VCL compatible. The VCL originally sat on top of the Windows 3.1 API, and frankly, trying to force non-Windows platforms into that mold doesn’t help anyone. It also wouldn’t get away from the ‘new and untried framework’ issue - any VCL-like interface that attempts to sit on top of Cocoa is going to have as much to do with the real VCL internally as FMX does, with as much custom control compatibility too (i.e., nil). As for Windows, why would anyone use a VCL lookalike when the real VCL is available?

    OTOH, the differences between the VCL and FMX can be exaggerated too. Quite apart from sharing the Delphi RTL, the basic component architecture is identical - FMX uses pretty much exactly the same streaming system as the VCL back in 1995.

    Lastly, if you want cross platform compatibility, don’t use GetTickCount -use TStopwatch instead, which has been around for a few releases now.

  3. Larry Hengen Says:

    @Stefan,

    I was actually referring to the performance of the application. It may have been a bit of an anomaly, or related to Update 4 specifically. I never encountered performance issues in previous releases of FMX with such a simple app.

    I’m not advocating complete FMX compatibility with VCL. Just as much as reasonable possible (I would never expect common sense to be abandoned). I think the benefits of such compatibility would be great. Perhaps this view will be confirmed in the latest Delphi survey.

    I agree about the RAD resulting in problems with the separation of UI from business code, but as much as you may like to keep it in your domain layer, it takes a lot of discipline, or TDD to keep it from creeping into forms even in the form of validation logic.

  4. Larry Hengen Says:

    @Chris,

    I would not expect anyone to use a VCL look alike when the real VCL was available, and that is part of the point. Developers wouldn’t have to choose if FMX exposed a VCL like API for basic functionality. A thought, which I believe EMB had, as much of the FMX object model is the same as the VCL. The issue is that there are some inconsistencies that limit the benefits of this approach.

    With a more consistent API developers could keep writing for VCL while using FMX for XPlatform support without maintaining multiple versions of their source (one for each UI layer). Otherwise, you have to choose FMX over VCL if you ever think you might want XPlatform support, and there isn’t the same breadth of third party support yet for FMX. The chances are it will not be there for some time considering how long it’s been since FMX was released.

  5. Stefan Glienke Says:

    @Larry:

    “I personally feel that my coding productivity was higher in D7 with CodeRush than the Delphi XE with GExperts and CnPack. Part of the reason for this is the code parsing the IDE performs in the main thread. Type in Begin incorrectly, and you can be waiting for 10 seconds while the IDE tries to figure out what is going on.”

    That was not about the IDE performance? What then?

  6. Larry Hengen Says:

    @Stefan,

    Sorry, I misread your comment. I use CnPack for the code navigation features (drop down class and method lists) and a few other editor improvements including structural highlighting. I will check out IDEFixPack for XE. I used it for D7 and it made a world of difference. It amazes me, that EMB doesn’t incorporate some of these fixes from Andy into their source trees.

    As always, I appreciate your comments…

  7. Tauseef Shahzad Says:

    I think that least Embarcadero could do was to keep FMX as close to VCL as possible. Comeon, Lazarus is much more close to VCL and still crossplatform.

    Agreed, Lazarus 1.0 is years behind delphi, but can be used as proof of concept. I can write simple application windows and port it to Apple or the other way round with little or no changes.

    I strongly believe Embarcadero has more brains (Paid ones) that can do it.

  8. Alex Fanti Says:

    Just FYI (in case anyone else is using GetTickCount)… in XE3 it’s now a class function of TThread (i.e. TThread.GetTickCount).

  9. elter Says:

    WebFMX permite que aplicações Delphi-FireMonkey sejam publicadas na Web e acessadas por qualquer dispositivo em browser HTML5

    WebFMX potencializa o uso do framework HD FireMonkey ampliando a disponibilidade de aplicações para que possam ser acessadas em qualquer lugar por qualquer dispositivo. Uma aplicação compilada com os runtimes de WebFMX se torna uma aplicação de plataforma dual (Windows e HTML5). Pode ser oferecida, por exemplo como um serviço na nuvem (SaaS) e dispensa a necessidade de adotar as complexas e caras soluções de virtualização. As aplicações compiladas com WebFMX são mostradas no browser similarmente ao tradicional look and feel de Windows. WebFMX também inclui seu próprio servidor web.

    - Cliente Multi-Dispositivo, Multi-Plataforma e Multi-Browser - Impressão remota em PDF - Redirecionamento do método OpenFile para permitir upload de arquivos a partir da máquina cliente - Método de DownloadFile disponível - Objeto RemoteInfo, com informações sobre o navegador - Gestão de timeout, para permitir recuperar o controle de uma aplicação quando a conexão é perdida - Implementação de MessageDialog e InputQuery - Dois modos para fontes: WebFont e Bitmap. - Eventos para controlar o redimensionamento, disconexão e WebFonts. - SDK con biblioteca JavaScript.

    O processo de converter uma aplicação FireMonkey com WebFMX é quase instantâneo e requer uma única linha de código. O cliente WebFMX é baseado em HTML5 e outros conhecidos padrões da Web.

    WebFMX é perfeito para desenvolvedores Delphi que estão planejando usar o Framework HD e empresas que possuem aplicações Delphi-Firemonkey e querem ampliar a disponibilidade para a Web e acesso por dispositivos móveis.

    Acesse os exemplos: http://elters.no-ip.biz:6880

    https://webfmx.thinrdp.net/

Leave a Reply