There is a very exciting improvement in Delphi, C++Builder and RAD Studio 11.0 Alexandria: the IDE now fully supports high DPI scaling on high-resolution screens. This means that if you use Windows and have a 4K or similar high-res display, the IDE will render crisply and clearly on your screen. In fact, if you have two screens with different scales, you can have different IDE windows on those multiple displays and each will render perfectly, crisp and clear, on each monitor. This high DPI scaling support using the VCL’s own support for perMonitorv2 scaling, which we introduced a couple of releases ago, plus our own image collection and virtual image list components. In other words, we use the same tools we make available to you.

Importantly, high DPI support includes support in the code editor, for crisp text, and when designing forms, both VCL and FMX. (If you’ve started RAD Studio 11 and thought, ‘hey, my form is small!’ read onwards – we have settings controlling the scaling in the VCL form designer and you’re set to unscaled by default.)

Let’s dig into how the IDE behaves on both high-res and low-res displays today, some interesting notes about how it was implemented, and look at VCL form designing in particular.

High DPI Comparison

The best way to see the difference in the IDE is to use it. Using the IDE on a high-res display is like night and day – there are some things that screenshots only half convey, and what the RAD Studio 11 look and feel is like is one of them. In person, it’s an amazing difference.

But to show what we can just in a blog post, here is a great image Jim McKeeth created comparing the 10.4.2 and 11.0 IDEs:

You can see that the image on the right, in v11.0 Alexandria, the text and icons are clear no matter how large the display the IDE is placed on.

Background – why High DPI?

A typical scale set in Windows today is 200%. This is 2x the pixel density, which really means that for each pixel in the past, there are now four pixels (it is divided into two vertically and horizontally.) I am writing this on a 4K monitor, which is 2160 pixels high. That is 2 times 1080, a vertical resolution that before high DPI I used for years. To get everything to appear the same physical size onscreen, I need to scale by 2.

If an app doesn’t support high DPI (is ‘DPI unaware’), Windows will scale it up, but upscaling adds blurriness. It is much better if an app is aware of the scaling applied to the screen its window(s) are on and can draw crisply. We added support to the VCL for this in 10.3, supporting perMonitorv2 high DPI scaling (the latest and best of the options Windows provides) and adding in components for high-res icons and image drawing, providing better support for high-res images in toolbars and menus that Windows has inbuilt. The IDE, which is mostly built with the VCL, uses these and is a great demo of the VCL’s capabilities.

The IDE uses styles to draw its light, dark, and mist themes, and VCL styles also have support for high DPI scaling.

High DPI Form Designers

While the VCL’s high DPI support is largely a matter of enabling perMonitorv2 support in the Application > Manifest page of your project options and recompiling, plus updating images (more info below), and updating any custom drawing or hard-coded pixel constants to use the ScaleValue overloads to get the new point, value, rect etc for the high-DPI form, it’s not quite as simple as that. We had one specific area that doesn’t apply to customer applications that we needed to work on, and it was this that took most of our development effort. In fact, researching and prototyping the best approach here is one reason it took until v11 to implement high DPI in the IDE after we introduced support for the VCL itself in 10.3. That area is the VCL form designer. We’ve come up with a solution that we hope meets all needs.

You can scale the VCL form designer to any DPI (any scale.) This is done using the same scaling tech that the VCL uses when scaling itself at runtime, ie when an app is run and it needs to adjust its size and layout to match the display it’s on. This setting is in Tools > Options > User Interface > Form Designer > High DPI. When you change it, you’ll need to close and reopen the form designer to have an effect.

By default, when you open a form, the form is designed at 96 DPI – that is, at 100%. That means that if your IDE is at 200%, the form will appear smaller than the controls around it. One key bit of knowledge is that when a form is scaled, the Left, Height etc properties are changed – this is exactly the same as when you run an app and it is scaled; those values are multiplied by the screen scale. Designing at 100%, the default, means the form is not scaled at all: opening a form does not change the values stored in the DFM compared to opening it in, say, 10.4.2. If you install v11 and notice your forms look small, this is why: we made the default behaviour to not modify a form.

You can also let the form designer match your screen. This means a button on a form will match the size of a button in an IDE dialog: it will always match the screen scaling no matter the screen or what the scaling is (125%, 150%, 300%…) This is the most convenient if you just want to see your form the same size as everything else you interact with in the UI. In the IDE Options dialog, this is ‘Automatic’ because it will set it based on how the screen the designer is on whenever you open it.

Finally, you can set a specific scale that you use for form designing. This can be any scale – 125%, 300%, anything you like.

Windows and so the VCL uses integer coordinates for its sizes and locations. This means that any scaling — of any app — may not always be exactly precise. In practice, it’s fine when scaling once (such as when an app is run, and it scales up from the low-res coordinates with which it was designed.) It’s also fine scaling a few times, such as moving from one monitor to another after launching. It matters more when scaling many times (and this is one reason why we don’t have a feature where you design at any scale but scale down to 100% when saving.) So it is fine to design at high DPI at any scale, and run even at a lower scale – the VCL will scale your app correctly – but it is important to avoid scaling over and over again, which will happen if every time you open a form in the designer it’s opened at a different DPI. Therefore, if you work in a team, ‘Automatic’ may not be a good choice if you all have different screens, and so we recommend that your team choose a single common scale that you all use so that one person editing a form another has also edited does not cause a scale change.

FireMonkey Designer

The FireMonkey designer is much simpler. It simply scales to match the IDE’s own scale, the same as if you scale a FMX app in code. FireMonkey uses floating point coordinates and does not have the same technical considerations as VCL apps. In v11, we also changed FireMonkey on Windows to use a coordinate system based on device units, not pixels, meaning on Windows FMX forms can scale to the display scale better than in the past including with higher quality rendering.

Technical Changes

Component vendors don’t need any changes to the icons they supply with their components, since we have supported high-res component icons in PNG format since 10.2.2. Plugin or addon vendors have new APIs in the ToolsAPI to add images into the IDE’s internal high-res image collection (these are out of scope for this article, but check ToolsAPI.pas for TGraphicArray: each of these new overloads allows adding multiple sizes of an image to the image collection backing the IDE’s image lists.)

Internally, and this won’t affect any developer but may be interesting to know: each IDE form has its own image list. This is required for high DPI support since it is a form that scales, and two forms on two different screens can scale differently, so an image list cannot be shared between multiple forms or controls on multiple forms because the images may be the right size for one form but wrong for the other. In fact, in the past the IDE had multiple old-style image lists anyway, often one per form; but in the past, since old-style image lists store their own images, this also meant that many images were duplicated. A red delete X might have been in multiple image lists, and this made it hard to update icons.

The IDE now has a single central image collection. This holds all images used across the IDE (other than component icons, stored separately.) Multiple image lists in the IDE connect to this image collection. As part of that work, we used both software and the human eye to de-duplicate icons, so the image collection has a single copy of each. This has made it much easier to update icons. The image collection now has a comment field for each icon, too, which can be used to store whatever information you want: we use it to store notes about where and how the icon is used.

We hope this insight into the approach we took may be useful to you when updating your own software to high DPI. We also have comprehensive documentation on high DPI images here.

Other Changes

One final small change we made is to some of the IDE icons. Most icons were replaced with high-res (multi-res) versions, so they can be displayed crisply at any scale. However, we also redesigned some of the icons for the key parts of the product.

Some of the most key toolbar buttons in the whole IDE are Run With Debugging – this is what you use the IDE for, ultimately! – plus debug operations like step over, trace into, etc. These all now have new icons that have been specially designed for their purpose, to look clear but also illustrate what the operation is. They look like this:

The new Run with Debugging icon. It looks more like a Run symbol, and has a bug being squashed underneath.	Step Over – such a simple design! But I think a very elegant way of showing the concept

You might notice that the Run part looks like the older Delphi 7 run icon (less horizontally wide), the Platforms icon looks like one the IDE used to have that is circle of multiple parts (it’s meant to indicate unity from several different items), and some other icons have new versions too.

In addition, we moved to Consolas as the default font for the editor. Consolas is a very Delphi-like font – that is, it will feel natural to you if you’ve used the old default font Courier New in the past (which you can still use.) We also install several programmer’s fonts: Fira Code, Monoid, Source Code Pro, and so forth.

High DPI IDE

RAD Studio 11.0 brings a much-requested and very big overhaul of the IDE: full high DPI support. Rendering crisply and clearly on all screens, with support for form designing at multiple scales, and clear text with a new but familiar font in the editor, it’s one of the biggest changes and improvements we’ve made.