FireMonkey Fonts and Native Look & Feel

Since XE2 Update 4 was released, there have been a few online complaints (1, 2) about FireMonkey's fonts on Windows.  I had most of a blog post written explaining why it actually was fine, when I read that there will be a hot fix targeting this and other issues.  I guess it is an issue after all, then!

But when it comes to FireMonkey's text, there are more important things than antialiasing or fitting to the pixel grid.

From the perspective of text UI controls & fonts, this article will examine:

• FireMonkey as a cross-platform UI framework
• How FireMonkey actually looks on different OSes
• What you can do to improve the native look and feel of FireMonkey
• Some ideas for FireMonkey enhancements (because you shouldn't have to do anything.)

Transparent graphics with pure GDI (Part 2) - and introducing the TTransparentCanvas class

This is part 2 of a short series that examines alpha-aware graphics using native GDI only - not GDI+, not DirectX, and not with any other custom non-GDI graphics implementation.

This post will cover:

• Non-rectangular drawing
• Handling GDI's clobbering of the alpha channel
• Better use of per-pixel alpha (based on what's drawn, which is more useful than a horizontal gradient)
• Introduction of the TTransparentCanvas class: a TCanvas-like class allowing you to draw rectangles, ellipses, text etc as you normally would, including using TPen, TBrush and TFont.  It composes the layers of drawing as you go, building a per-pixel alpha-aware image.  It also allows you to draw on glass - something VCL applications traditionally have trouble with.

Previous posts in the series:

• Transparent Graphics with GDI (Part 1)
• Transparent Graphics with GDI (Part 1 ½)

If you're not very familiar with GDI and alpha transparency on Windows, including the intricacies of using AlphaBlend and its BLENDFUNCTION parameter, please (re-)read those before continuing.  Content in this post refers to classes and techniques introduced in the first two articles.

Free ~4GB of disk space used by XE2 installation files

Update: this may not be a good idea - see below.

Original post: I run on a rather disk-space-restricted system, with Windows running on a 50GB "disk" in VMWare Fusion.  50GB isn't much, but it's a lot when I only have a 128GB disk on the host machine, too (a speedy SSD.)  Most of that 50GB is validly used, but I had only 1GB free when I expected to have 5 or 6 - not enough to install XE2 Update 4.

The Disk Cleanup tool showed only a few megabytes of possible files to delete.  So I went hunting for large folders that didn't contain data I knew I wanted, and found the following in c:\Program Data:

(On Windows 7, c:\Program Data is the non-roaming 'all users' application data path, the path returned when passing CSIDL_COMMON_APPDATA to SHGetFolderPath.)

The eight folders with GUID names contained 3.83GB of files that appear to be part of the C++Builder XE2 installer and help installer.  They appeared to contain boost installation files, help update files, and what appear to be general updates: a lot of folders named after components or folders in the C++ Builder installation directory.  Luckily, the folders were compressed, but they still took up almost 4GB - that's about 8% of my hard disk space.  Deleting these has done no visible harm.  Together with a few other deleted files, I now have about 7GB free disk space, hopefully enough to install the XE2 update.

Follow this at your own risk, but if you are running C++Builder or Delphi on a virtual machine and disk space is low, try looking here.

Update: At this stage I was thinking 'Great!  I've got rid of 4GB of space that the installer for the version I'm about to get rid of used.  Now I can use that space to install update 4!'  But I soon found out:

Following the XE2U4 instructions, I tried to uninstalled XE2 from the Add/Remove Programs applet.  All the 'Uninstall' menu item did was remove the XE2 entry from the Programs list.  It was at this point that I realised the installation files I had deleted were probably also uninstallers.  I don't know why all 4GB are required, but it seems a fair conclusion that's what these folders / files were for.

When I ran the XE2U4 installer, it thought it was already installed, and so I chose the option to uninstall rather than repair.  Uninstalling showed several errors about 'unable to load required plugin', but seemed to mostly work.  I then re-ran the installer, and XE2U4 seemed to install itself properly.

So: if you desperately need space, deleting the old installation files seems to work ok, but might not be a wise idea.  It might be better to uninstall XE2, and then delete the old installation files, in order to free disk space.

Given this is at least the second (?) update to XE2 that has required uninstalling and reinstalling, and that the entire installation data set of 4GB or so seems to need to stay around in order to uninstall, it would be great to see this trimmed and a dedicated uninstall option provided by Embarcadero.  Of course, the best option is to always be able to update, not uninstall and reinstall.  At that point, the old installer becomes useless and can be removed.