High DPI awareness is must have feature for XE8.

-
High DPI awareness is must have feature for XE8.
Not only for Delphi IDE, but also for VCL and FMX frameworks. 
https://quality.embarcadero.com/browse/RSP-9678

Comments

  1. Lars FosdalNovember 5, 2014 at 2:24 AM

    Voted!

    ReplyDelete
  2. Tommi PramiNovember 5, 2014 at 2:35 AM

    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 :(

    ReplyDelete
  3. Jeroen Wiert PluimersNovember 5, 2014 at 2:47 AM

    Can you add that for Appmethod as well? So anonymous users can see it and Google search can index it?

    ReplyDelete
  4. David MillingtonNovember 5, 2014 at 2:52 AM

    Voted and commented.

    ReplyDelete
  5. Dobrin PetkovNovember 5, 2014 at 3:32 AM

    Voted

    ReplyDelete
  6. Lars FosdalNovember 5, 2014 at 4:13 AM

    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.

    ReplyDelete
  7. Dalija PrasnikarNovember 5, 2014 at 4:15 AM

    I added another closely related report

    VCL 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.

    ReplyDelete
  8. Dalija PrasnikarNovember 5, 2014 at 4:28 AM

    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...

    ReplyDelete
  9. Lars FosdalNovember 5, 2014 at 4:28 AM

    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.

    ReplyDelete
  10. Achim KalwaNovember 5, 2014 at 4:34 AM

    I don't have or use AppMethod.
    How do I add an report for AppMethod? Can I extend the current report or do I need to add a new one?

    ReplyDelete
  11. Dalija PrasnikarNovember 5, 2014 at 4:40 AM

    Lars Fosdal http://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx

    Add 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"/>
           
           
     

    ReplyDelete
  12. Steve MaughanNovember 5, 2014 at 7:42 AM

    Yep - High DPI awareness (or lack of) is the developers Y2K of our time (IMHO)

    ReplyDelete
  13. Jeroen Wiert PluimersNovember 5, 2014 at 9:44 AM

    Steve Maughan  I think it is even worse and comparable to the EUR introduction.

    ReplyDelete
  14. Dalija PrasnikarNovember 5, 2014 at 9:57 AM

    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.

    ReplyDelete
  15. Ilya SNovember 5, 2014 at 12:42 PM

    Jeroen Wiert Pluimers what is "EUR introduction" all about?

    ReplyDelete
  16. David MillingtonNovember 5, 2014 at 12:56 PM

    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?

    ReplyDelete
  17. Dalija PrasnikarNovember 6, 2014 at 12:05 AM

    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.

    ReplyDelete
  18. Lars FosdalNovember 6, 2014 at 12:09 AM

    Has anyone seen a ImageList component which supports vector graphics that render proper sized bitmaps as needed?

    ReplyDelete
  19. David MillingtonNovember 6, 2014 at 2:36 AM

    Dalija Prasnikar Thanks!
    Lars Fosdal No... but it sounds like a great component to write ;)

    ReplyDelete
  20. Michael SchwarzlNovember 6, 2014 at 9:01 AM

    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.

    ReplyDelete
  21. Jeroen Wiert PluimersNovember 6, 2014 at 11:06 AM

    Ilya S introducing the Euro monetary unit.

    ReplyDelete
  22. Ilya SNovember 6, 2014 at 11:37 AM

    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?

    ReplyDelete
  23. David MillingtonNovember 6, 2014 at 12:06 PM

    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.

    http://ta.twi.tudelft.nl/users/vuik/wi211/disasters.html#euro , but read the others too.

    ReplyDelete
  24. Dalija PrasnikarNovember 7, 2014 at 12:50 AM

    Michael Schwarzl Probably the best solution would be to design in DPI independent sizes and then apply scaling directly on those. 

    Android design works that way, and it works very well. 
    http://developer.android.com/design/style/metrics-grids.html

    ReplyDelete
  25. David MillingtonNovember 7, 2014 at 2:57 AM

    Dalija Prasnikar But Delphi doesn't have any support for that, does it? (Maybe in FMX, but not VCL?)

    ReplyDelete
  26. Dalija PrasnikarNovember 7, 2014 at 3:21 AM

    David Millington Delphi does not have any such support. And last time I checked (it has been a while) FMX didn't have it either.

    Basically, 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.

    ReplyDelete
  27. David MillingtonNovember 7, 2014 at 3:26 AM

    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.

    ReplyDelete
  28. Dalija PrasnikarNovember 7, 2014 at 5:12 AM

    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.

    ReplyDelete
  29. Alex HNovember 7, 2014 at 6:03 PM

    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).

    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.

    ReplyDelete
  30. Dalija PrasnikarNovember 8, 2014 at 12:52 AM

    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.

    ReplyDelete
  31. Alex HNovember 13, 2014 at 8:20 AM

    Thank you for the hint about the manifest! The tutorial has been updated - please have a look at the new version: Download link:
    http://www.helpandmanual.com/downloads_delphi.html

    ReplyDelete
  32. Dalija PrasnikarNovember 13, 2014 at 12:13 PM

    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 :)

    ReplyDelete
  33. Ilya SNovember 28, 2014 at 12:23 PM

    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?

    ReplyDelete
  34. Warren PostmaMarch 15, 2015 at 2:55 PM

    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.

    ReplyDelete
  35. Ilya SMarch 15, 2015 at 3:31 PM

    Warren Postma care to share useful details or working example in a blog post? :)

    ReplyDelete
  36. Dalija PrasnikarMarch 16, 2015 at 3:21 AM

    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.

    ReplyDelete
  37. Warren PostmaMarch 16, 2015 at 1:53 PM

    It's proprietary code to my employers. I will find out if I can make an open source version.

    ReplyDelete
  38. Warren PostmaMarch 17, 2015 at 11:31 AM

    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.

    ReplyDelete
  39. Ilya SApril 4, 2015 at 2:15 PM

    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

      

    "
    https://msdn.microsoft.com/en-us/library/ms171868(v=vs.110)
    It brings no value for Delphi apps or IDE, right?

    ReplyDelete

Post a Comment