And at least you could develop in High DPI and it should still work, if you have default (Normal what not) DPI it works OK, but developing on High DPI box gives all sorts of problems :(
Attached two examples to the issue from my 3K laptop. One that shows the fuzzy IDE, another that shows how our Delphi app has the same fuzziness. Namedropping Marco Cantù to ensure maximum attention.
Jeroen Wiert Pluimers Adding report for Appmethod would be a request for Achim Kalwa since he submitted report for RAD Studio.
But, I am not sure that adding it would make too much difference. I would rather have RAD Studio Quality Portal accessible to all, but that is another issue...
Dalija Prasnikar - Ref. your comment about high DPI awareness - Is there a blog post or similar that exemplifies the manifest and the steps required to implement it?
We use a lot of TMS components, and I guess they will have a bit of work to do as well.
Steve Maughan Jeroen Wiert Pluimers I would say that consequences of Y2K were much more serious, but this is without doubt serious issue that has been ignored for far too long.
Even in Windows 95 era some people were using large fonts on some (not so high DPI) monitors. This issue is not from yesterday. For the last 15 years I am writing applications that behave well on any DPI setting and it is beyond my comprehension how and why this has not been dealt with yet.
Dalija Prasnikar From what I gather, writing high-DPI apps in Windows (not just Delphi) can be tricky - there apparently isn't much system support. Can you elaborate on what you do to make your apps work well, please?
David Millington There is system support for writing high DPI apps, but it is not fully implemented (or should I say it is legging behind).
Delphi has support for creating high DPI apps. Some issues became more prominent lately with introduction of manifests and now with Windows 8.1 and per-monitor DPI system.
To make high DPI aware application, first step is to include custom manifest with dpiAware section (see my reply to Lars Fosdal ) or call SetProcessDPIAware early in your app. I prefer manifest approach.
Next thing to do is to make sure that all your forms have Scaling property enabled. That will automatically handle form scaling. However, any forms or controls you create in code you will have to scale yourself calling ScaleBy method.
Scaling controls with fonts is the most problematic because at higher DPI settings text tends to occupy more space. Make sure that you leave enough room for expanding textual data.
When you have done all that, you can change your Windows scaling settings and test if everything is properly scaled and positioned. I always test with 125% and 150% scaling and from my experience everything that looks fine at 150% will look fine on larger scale too.
If you also use some image resources, you should also provide them in larger sizes if necessary.
Dalija Prasnikar How would you deal with scaling when a user drags your application from one monitor to another with a different dpi setting in Windows 8.1? You cannot reapply another dpi setting, because of the MulDiv operation Delphi is using to calculate the new sizes. So the controls would become smaller and smaller.
Jeroen Wiert Pluimers Thanks! I should have known it. But I fail to see the connection between Y2K and EURO introduction. Much software at the time had to be rewritten?
Off topic, but I found this fascinating page 'Disasters Caused By Numerical Errors' - which are almost all software errors - which includes a section about the euro.
Dalija Prasnikar You could manage it with FMX with some manual code. Design is in floating-point units and you can scale arbitrarily. You'd still have to do all the work about figuring out the right scale and applying it.
David Millington Well, FMX forms do not have Scale method or property that would rescale whole form. And as far as I can tell Scale property in FMX controls is there for achieving goofy effects and not for high DPI support (I may be wrong). Scaling of FMX control only scales size and not control position.
I don't know how is FMX scaling implemented on iOS or Android, but on Windows it is non-existent because TDeviceDisplayMetrics.PixelsPerInch always returns 96, and IFMXWindowService.WindowScale always returns 1.
The only thing I managed to get automatically scaled are menus. And If I force scaling of controls, they are blurry. I guess we can thank Pixel Perfect styling for that.
Right now VCL is much more dpi aware than FMX. It only lacks per-monitor dpi support.
It is not THAT complicated, although the devil is in the detail. I happen to be writing a tutorial on exactly this topic, including a demo application, that is per-monitor DPI aware. The tutorial discusses the pros and cons of system DPI-awareness and per-monitor DPI-awareness. VCL only, not FMX (yet).
Alex H Custom manifest included in your application is not right for Windows 8.1 and per-monitor dpi awareness. It also lacks list of supported OS GUIDs and without that Windows tend to guess your apps capabilities, sometimes in wrong way.
Alex H You are still missing OS GUIDs in manifest, although it seems that dpi awareness is working properly. Cannot properly test on Windows 8.1 since I am currently running it only with single monitor and plugging another (even temporarily) looks like mission impossible :)
An interesting view to the other side of dev on Windows - WPF http://www.theregister.co.uk/2014/11/27/pity_the_poor_windows_developer_the_tools_for_desktop_development_are_in_disarray/?page=2 - "not making it buggy as hell on different graphics cards" - "dark art based upon off-screen rendering of XAML controls that change with each minor .NET release (which are now in-place upgrades, thereby breaking your clients' apps when they install a simple update)." (this one is about printing, not sure is appropriate here) - broken touch support So what? Does WPF have similar problems as FMX?
Warren Postma Tell me about it... I decided that I don't have time to implement it myself. BTW, did you have to make direct changes in VCL units, or you managed to implement it on top of them.
Incidentally, I'd be happy if XE7 (or XE8) supported High DPI even properly from the IDE. There are weird IDE bugs like popup menus and main menu drop downs being in the wrong place, on my computer which has a 110 DPI monitor, on Windows 8.1.
Something in .NET 4.5.1-4.6 preview has caught my eye: "Resizing in Windows Forms controls. You can use the system DPI setting to resize components of controls (for example, the icons that appear in a property grid) by opting in with an entry in the application configuration file (app.config) for your app
Voted!
ReplyDeleteAnd at least you could develop in High DPI and it should still work, if you have default (Normal what not) DPI it works OK, but developing on High DPI box gives all sorts of problems :(
ReplyDeleteCan you add that for Appmethod as well? So anonymous users can see it and Google search can index it?
ReplyDeleteVoted and commented.
ReplyDeleteVoted
ReplyDeleteAttached two examples to the issue from my 3K laptop. One that shows the fuzzy IDE, another that shows how our Delphi app has the same fuzziness.
ReplyDeleteNamedropping Marco Cantù to ensure maximum attention.
I added another closely related report
ReplyDeleteVCL and FireMonkey lack Per-Monitor DPI support for Windows 8.1
https://quality.embarcadero.com/browse/RSP-9679
Hopefully, Embarcadero will have enough time to investigate those issues and provide solutions for XE8.
Jeroen Wiert Pluimers Adding report for Appmethod would be a request for Achim Kalwa since he submitted report for RAD Studio.
ReplyDeleteBut, I am not sure that adding it would make too much difference. I would rather have RAD Studio Quality Portal accessible to all, but that is another issue...
Dalija Prasnikar - Ref. your comment about high DPI awareness - Is there a blog post or similar that exemplifies the manifest and the steps required to implement it?
ReplyDeleteWe use a lot of TMS components, and I guess they will have a bit of work to do as well.
I don't have or use AppMethod.
ReplyDeleteHow do I add an report for AppMethod? Can I extend the current report or do I need to add a new one?
Lars Fosdal http://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx
ReplyDeleteAdd following section to your application custom manifest -> Project Options -> Application -> Runtime themes - select custom manifest
http://schemas.microsoft.com/SMI/2005/WindowsSettings">
true
Above section does not make application DPI aware for Windows 8.1. In order to have that you have to replace true with true/PM
However, that will cause issues for people having multiple monitors with different DPI settings on windows 8.1
Complete manifest I am using in my applications:
-This Id value indicates the application supports Windows Vista functionality ->
-This Id value indicates the application supports Windows 7 functionality->
type="win32"
name="MyCompany.AppName"
version="1.0.0.0"
processorArchitecture="*"/>
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*"/>
http://schemas.microsoft.com/SMI/2005/WindowsSettings">
true/PM
level="asInvoker"
uiAccess="false"/>
Yep - High DPI awareness (or lack of) is the developers Y2K of our time (IMHO)
ReplyDeleteSteve Maughan I think it is even worse and comparable to the EUR introduction.
ReplyDeleteSteve Maughan Jeroen Wiert Pluimers I would say that consequences of Y2K were much more serious, but this is without doubt serious issue that has been ignored for far too long.
ReplyDeleteEven in Windows 95 era some people were using large fonts on some (not so high DPI) monitors. This issue is not from yesterday. For the last 15 years I am writing applications that behave well on any DPI setting and it is beyond my comprehension how and why this has not been dealt with yet.
Jeroen Wiert Pluimers what is "EUR introduction" all about?
ReplyDeleteDalija Prasnikar From what I gather, writing high-DPI apps in Windows (not just Delphi) can be tricky - there apparently isn't much system support. Can you elaborate on what you do to make your apps work well, please?
ReplyDeleteDavid Millington There is system support for writing high DPI apps, but it is not fully implemented (or should I say it is legging behind).
ReplyDeleteDelphi has support for creating high DPI apps. Some issues became more prominent lately with introduction of manifests and now with Windows 8.1 and per-monitor DPI system.
To make high DPI aware application, first step is to include custom manifest with dpiAware section (see my reply to Lars Fosdal ) or call SetProcessDPIAware early in your app. I prefer manifest approach.
Next thing to do is to make sure that all your forms have Scaling property enabled. That will automatically handle form scaling. However, any forms or controls you create in code you will have to scale yourself calling ScaleBy method.
Scaling controls with fonts is the most problematic because at higher DPI settings text tends to occupy more space. Make sure that you leave enough room for expanding textual data.
When you have done all that, you can change your Windows scaling settings and test if everything is properly scaled and positioned. I always test with 125% and 150% scaling and from my experience everything that looks fine at 150% will look fine on larger scale too.
If you also use some image resources, you should also provide them in larger sizes if necessary.
Has anyone seen a ImageList component which supports vector graphics that render proper sized bitmaps as needed?
ReplyDeleteDalija Prasnikar Thanks!
ReplyDeleteLars Fosdal No... but it sounds like a great component to write ;)
Dalija Prasnikar How would you deal with scaling when a user drags your application from one monitor to another with a different dpi setting in Windows 8.1? You cannot reapply another dpi setting, because of the MulDiv operation Delphi is using to calculate the new sizes. So the controls would become smaller and smaller.
ReplyDeleteIlya S introducing the Euro monetary unit.
ReplyDeleteJeroen Wiert Pluimers Thanks! I should have known it. But I fail to see the connection between Y2K and EURO introduction. Much software at the time had to be rewritten?
ReplyDeleteOff topic, but I found this fascinating page 'Disasters Caused By Numerical Errors' - which are almost all software errors - which includes a section about the euro.
ReplyDeletehttp://ta.twi.tudelft.nl/users/vuik/wi211/disasters.html#euro , but read the others too.
Michael Schwarzl Probably the best solution would be to design in DPI independent sizes and then apply scaling directly on those.
ReplyDeleteAndroid design works that way, and it works very well.
http://developer.android.com/design/style/metrics-grids.html
Dalija Prasnikar But Delphi doesn't have any support for that, does it? (Maybe in FMX, but not VCL?)
ReplyDeleteDavid Millington Delphi does not have any such support. And last time I checked (it has been a while) FMX didn't have it either.
ReplyDeleteBasically, some deeper root changes are in order and I don't think current design system will be able to exist as is for much longer.
Per-monitor DPI awareness is game changer and you can either be in the game or out. There is no "in between" option.
Dalija Prasnikar You could manage it with FMX with some manual code. Design is in floating-point units and you can scale arbitrarily. You'd still have to do all the work about figuring out the right scale and applying it.
ReplyDeleteDavid Millington Well, FMX forms do not have Scale method or property that would rescale whole form. And as far as I can tell Scale property in FMX controls is there for achieving goofy effects and not for high DPI support (I may be wrong). Scaling of FMX control only scales size and not control position.
ReplyDeleteI don't know how is FMX scaling implemented on iOS or Android, but on Windows it is non-existent because TDeviceDisplayMetrics.PixelsPerInch always returns 96, and IFMXWindowService.WindowScale always returns 1.
The only thing I managed to get automatically scaled are menus. And If I force scaling of controls, they are blurry. I guess we can thank Pixel Perfect styling for that.
Right now VCL is much more dpi aware than FMX. It only lacks per-monitor dpi support.
It is not THAT complicated, although the devil is in the detail.
ReplyDeleteI happen to be writing a tutorial on exactly this topic, including a demo application, that is per-monitor DPI aware. The tutorial discusses the pros and cons of system DPI-awareness and per-monitor DPI-awareness. VCL only, not FMX (yet).
Here's a first version of the tutorial:
http://download.ec-software.com/delphi-developers-guide-4k.zip
The archive includes the eBook plus a Delphi demo with source.
Alex H Custom manifest included in your application is not right for Windows 8.1 and per-monitor dpi awareness. It also lacks list of supported OS GUIDs and without that Windows tend to guess your apps capabilities, sometimes in wrong way.
ReplyDeleteThank you for the hint about the manifest! The tutorial has been updated - please have a look at the new version: Download link:
ReplyDeletehttp://www.helpandmanual.com/downloads_delphi.html
Alex H You are still missing OS GUIDs in manifest, although it seems that dpi awareness is working properly. Cannot properly test on Windows 8.1 since I am currently running it only with single monitor and plugging another (even temporarily) looks like mission impossible :)
ReplyDeleteAn interesting view to the other side of dev on Windows - WPF
ReplyDeletehttp://www.theregister.co.uk/2014/11/27/pity_the_poor_windows_developer_the_tools_for_desktop_development_are_in_disarray/?page=2
- "not making it buggy as hell on different graphics cards"
- "dark art based upon off-screen rendering of XAML controls that change with each minor .NET release (which are now in-place upgrades, thereby breaking your clients' apps when they install a simple update)." (this one is about printing, not sure is appropriate here)
- broken touch support
So what? Does WPF have similar problems as FMX?
I have implemented Win 8.1 per monitor DPI awareness for a Delphi VCL application, and it's trickier than you'd like to think.
ReplyDeleteWarren Postma care to share useful details or working example in a blog post? :)
ReplyDeleteWarren Postma Tell me about it... I decided that I don't have time to implement it myself. BTW, did you have to make direct changes in VCL units, or you managed to implement it on top of them.
ReplyDeleteIt's proprietary code to my employers. I will find out if I can make an open source version.
ReplyDeleteIncidentally, I'd be happy if XE7 (or XE8) supported High DPI even properly from the IDE. There are weird IDE bugs like popup menus and main menu drop downs being in the wrong place, on my computer which has a 110 DPI monitor, on Windows 8.1.
ReplyDeleteSomething in .NET 4.5.1-4.6 preview has caught my eye:
ReplyDelete"Resizing in Windows Forms controls. You can use the system DPI setting to resize components of controls (for example, the icons that appear in a property grid) by opting in with an entry in the application configuration file (app.config) for your app
"
https://msdn.microsoft.com/en-us/library/ms171868(v=vs.110)
It brings no value for Delphi apps or IDE, right?