I am currently trying to address a couple of the remaining High DPI issues of the VCL in Delphi 10.2.3. As the test field is pretty wide I can only test for a fraction of the combinations. Thus I am looking for some testers with non-standard DPI layouts (i.e. at least one monitor set to something different than 100%).
I am currently trying to address a couple of the remaining High DPI issues of the VCL in Delphi 10.2.3. As the test field is pretty wide I can only test for a fraction of the combinations. Thus I am looking for some testers with non-standard DPI layouts (i.e. at least one monitor set to something different than 100%).
The program to test comes in two flavors: One reference compiled with the standard VCL and HighDPI enabled in the project setting and the actual test version with my changes to the VCL code and a tweaked manifest.
Testing requires to start the program and if available drag to a monitor with another DPI and back. The testing version should look more or less the same while the reference version will most likely show some problems. I am interested in any problems with the testing version.
Unfortunately I can only provide a compiled exe and the sources of the project, but not the changes I made to the VCL (due to legal restrictions). So you better trust me here 😇.
https://drive.google.com/open?id=1c9Dd2Tg_oomT77uuWKMVWrn7qk7mo5cC
https://drive.google.com/open?id=1c9Dd2Tg_oomT77uuWKMVWrn7qk7mo5cC
The program to test comes in two flavors: One reference compiled with the standard VCL and HighDPI enabled in the project setting and the actual test version with my changes to the VCL code and a tweaked manifest.
Testing requires to start the program and if available drag to a monitor with another DPI and back. The testing version should look more or less the same while the reference version will most likely show some problems. I am interested in any problems with the testing version.
Unfortunately I can only provide a compiled exe and the sources of the project, but not the changes I made to the VCL (due to legal restrictions). So you better trust me here 😇.
https://drive.google.com/open?id=1c9Dd2Tg_oomT77uuWKMVWrn7qk7mo5cC
https://drive.google.com/open?id=1c9Dd2Tg_oomT77uuWKMVWrn7qk7mo5cC
Superb. Finally someone does something! An overview: quality.embarcadero.com - Issue Navigator - Embarcadero Technologies
ReplyDeleteThere's no reason you cannot share in patch form the changes you made. If you can't share that, then what is the point of this? Are you working on this for your own use, or for embarcadero?
ReplyDeleteUwe Raabe I'm glad you are on the field test and you are helping to fix the HighDPI issues. Here are some results from my single-monitor Windows 10 with 125% scaling.
ReplyDeleteHighDpiRef.exe:
- Alignment problems of Buttons on TabSheet1
- Toolbar2 not visible
- Toolbar4 not visible
HighDpiTest.exe:
- Alignment of Buttons on TabSheet1 is good.
- Toolbar2 not visible
- Toolbar4 not visible
(both Toolbars are visible when running with 100% scaling)
With DPI 240 one screen, main menu width, popup owner drawn menu width, controls in tab sheet and gridpanel appear fixed. I did not observe any other issues with either of the executables.
ReplyDeleteVincent Parrett I am working on it because it has to be done. Perhaps Embarcadero will take over my work - at least partly, but I am not sure about that. I also thought about distributing the patches, but as this is still work in progress it may happen at a later time. In any case I am going to offer it to Embarcadero first to incorporate it into a future version.
ReplyDeleteWell hopefully you make more progress on it than embarcadero have. Don't forget to test with VCL Themes (ducks and runs for cover) ;)
ReplyDeleteVincent Parrett My findings about the VCL Theme is that the whole system probably needs a big overhaul to support per monitor DPI in a way Delphi deserves. So for the moment I am going to stick to the Windows theme and may tackle the VCL themes later.
ReplyDeleteThe biggest issue I have found so far (and the one that made me give up) is the non client area (title bar, min/max/close buttons) do not scale properly when vcl themes are enabled, which makes themes+highdpi unusable together.
ReplyDeleteAchim Kalwa I am not able to reproduce that behavior here. Can you contact me directly? You can find my phone number on my website under Impressum.
ReplyDeleteEdit: OK, I got it now. Windows needed a restart first.
We are very interested in your findings and any required patches.
ReplyDeleteAchim Kalwa Can you download the latest version and try again, please? The problem you are seeing is not directly related to the DPI setting, but more an error in the TDPIAwareImageList component used in this application. Actually the toolbars are visible, but the images are simply missing.
ReplyDelete> So you better trust me here
ReplyDeleteWe do, but having the .exe files unsigned makes it slightly less likely that people will test them. Win 10 complains:
"Windows protected your PC
Windows Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.
App:
HighDPITest.exe
Publisher:
Unknown publisher "
I'm using Remote Desktop into my office PC now, but I was able to confirm that the Test version works better than the Ref version.
We bought 10.2.3 licenses to upgrade from XE6 just because it now (finally) supposedly supported HighDPI properly. Really disappointing if patches are still needed...
Hallvard Vassbotn Good point!
ReplyDeleteLatest upload contains signed exe files.
ReplyDeleteHallvard Vassbotn Vincent Parrett Can you contact me by email, please? uwe_at_uweraabe_dot_de
ReplyDeleteWe tested as well and I will send you the result to the uwe_at_uweraabe_dot_de E-Mail.
ReplyDeleteThank you for your efforts!
Uwe Raabe Hi Uwe. With the new version, the toolbars display fine.
ReplyDeleteI tested against a single-DPI setup to provide another data point. I am running Win7 x64, 120 DPI, and confirm that the test application works correctly. In the ref application TabSheet1.Button3, .Button4 and .Button3 are not aligned to the top right, bottom left and bottom right corners respectively.
ReplyDeleteThere is a new version available, that also fixes the TCheckListBox issue.
ReplyDeleteI have also changed the icons to alpha blended ones and added 256 pixel versions. The DpiAwareImageLists now use ScaleDown instead of ScaleNearest. I have the impression that this results in better images.
If only someone could compile the IDE now with my VCL changes...
I just tested your latest version, and it's a significant improvement over the stock vcl, well done! 10.2.3 still has problems with themes and the non client area, howerver your patches seem to fix that. Testing on a dual monitor with the second monitor set a 175%, I can move between monitors with no aparent issues! This is really promising!
ReplyDeleteMarco Cantu Maybe you want to receive and publish patches that Uwe Raabe has developed to fix some of the remaining HighDPI issues in the VCL..? :)
ReplyDeleteUwe Raabe Works nice. Well done! Small point. Instead of
ReplyDeleteTTask.Run(
procedure
begin
TThread.Queue(nil, NotifyScale);
end);
you can use
TThread.ForceQueue(nil, NotifyScale);
Some agility on the part of Embarcadero is needed on this high priority issue. They have been extremely conservative in adopting suggested solutions to quality issues even when well-thought changes are proposed by respected members of the community. The need for extensive testing to prevent regressions, combined with resource constraints may partly explain this. What is happening in this thread may become a good model for the future. Extensive testing is done by the community saving scarce resources for Embarcadero. IMHO, it would be better though if the code changes were also released, so that others can review and contribute to the suggested changes.
ReplyDeleteKiriakos Vlahos Indeed, ForceQueue can be used here. I actually started that work in 10.1, where this was not available. When publishing it I may decide to support only 10.2 and above.
ReplyDeleteVery nice - works well here. But the TDPIAwareImageList has a big drawback: it cannot serve 2 forms with different DPI settings, can it? For every form that is shown on a second monitor with different DPI, you need a secondary image list. Is it correct?
ReplyDelete/sub
ReplyDeleteOndrej Pokorny Yes, that is correct. The component can adjust to one DPI at a time and it has to be placed on the form to get notified of any DPI change. It should be no problem to place the source image lists that the DPIAwareImageList links to onto a common datamodule and have multiple DPIAwareImageLists link to them.
ReplyDeleteI actually don't see this as a drawback. TDPIAwareImageList is merely a wrapper around a couple of image lists with different sizes, which automatically selects the proper size according to the current DPI of the form (well, it optionally creates a scaled temporary image list when necessary). One can achieve the same result by switching image lists manually when DPI changes in a form. That would be just a bit more tedious.
Could you please give the test/ref exes different names? On my monitor setup, (primary 120dpi 125%/secondary 96dpi 100%) the differences are not so obvious when I have both open at the same time.
ReplyDeleteThe only glitch that I saw, but cannot reproduce reliably is that the row height and icons in the listview (report mode) were not calculated/displayed properly when dragging the application from 120dpi to 96dpi. Sometimes one and a quarter (of the same) icon were shown.
The problem is that you can never know what target DPI your user has - so you need one TDPIAwareImageLists for every DPI/imagewidth combination that you have to create in runtime and assign them to controls manually in your code. Even worse: shared menus in data modules - you need to check at what form/monitor/DPI they are going to be shown and assign the right TDPIAwareImageList before they popup.
ReplyDeleteNo, this is not a good general solution.
FYI: I made HighDPI support (along with a new multi-resolution image list) for Lazarus/LCL: wiki.freepascal.org - TImageList - Free Pascal wiki and http://wiki.lazarus.freepascal.org/High_DPI#High_DPI_in_Lazarus_1.8_and_above
One image list serves it all - different DPI, different image sizes. If the needed resolution isn't there, an existing resolution is automatically up/downscaled.
Basically everything you need is to create one image list and provide 16px, 24px and 256px resolutions (or whatever you like) and that's it. If the user draws the form to another monitor, the imagelist automatically provides the needed resolution. If a menu is popped-up, it gets automatically the right resolution from the image list. No need to code, no need to duplicate image lists.
Ondrej Pokorny I don't agree with your conclusion. You only need one DPIAwareImageList per Form and design image size. Let's say you have a toolbar where the user can choose between small, medium and large images. Then you place one TDynamicImageList on the form and three TDPIAwareImageLists. The dynamic image lists links to the three dpi aware image lists and those to your base image lists for the different sizes you want to provide. Switching between small, medium and large is just setting the ImageIndex of the dynamic image list. The DPI is automatically adjusted. No need to code, no need to duplicate image lists.
ReplyDeleteThe advantage of this approach is that you can still have that type of TCustomImageList that you prefer. There are plenty of third party image lists on the market and TDynamicImageList and TDPIAwareImageList work with all of them. I deliberately choose not to implement a new type of image list managing all the images itself.
I prefer my approach, but perhaps I am biased.
Uwe Raabe Yes, you said it yourself - you need at least one TDynamicImageList on every form. If your application has dozens of forms... Your solution (image list container) is the simple one.
ReplyDeleteActually, it's not possible to implement the multiple-resolution image list as a new type of image list. The TCustomImageList itself and all imagelist-aware controls need to be modified to support a multiple resolution image list. Something that must be done on VCL-level and not as an extension package. But it's not that much work. I remember I needed about a week for it in the LCL, with backwards compatibility remained.
Uwe Raabe just to make it clear: you did a good job - actually you cannot do anything better than an image list container if you don't want to modify the VCL. But it's not a true solution. A true solution is when Delphi provides a High-DPI aware TImageList out-of-the-box - and really the basic TImageList and not a new component. If they claim High-DPI Awareness and 4K monitors support, they definitely should provide a suitable image list as well.
ReplyDeleteLübbe Onken Do you refer to the Form.Caption when you say different names?
ReplyDeleteFor instance. Just some place where it is in plain sight. Or put it in the panel where you show the resolution.
ReplyDeleteI noticed that the order of the icons on the toolbar is different, but can’t tell which application is which.
Lübbe Onken I changed the Caption now. This is also convenient as you can create new forms with the several Copy buttons. The new version is available form the GDrive link.
ReplyDeleteThe button order is a known problem with the current Delphi version: quality.embarcadero.com - Log in - Embarcadero Technologies
This is one of the issues addressed with these patches.
You can recreate whatever monitor configuration you want, on your own computer. Just install VirtualBox, create VM with more than one monitor and setup them as you need.
ReplyDeleteМикола Петрівський That is exactly what I do here (although with VMware). As the combinations are many I am just looking for others to find the problematic cases.
ReplyDelete/sub
ReplyDeleteA patch may be kosher...
ReplyDeleteAny news here Uwe Raabe?
ReplyDeleteYou arrived at a set of VCL patches that are needed to get HighDPI support to work properly?
Are the patches only on specific components or more general in the core VCL logic for scaling?
Planning a mechanism to publish the patches?
Hallvard Vassbotn The patches address several problems found in the VCL code regarding HighDPI (about 20 QP issues and a couple of general things). Currently they are handed over to Embarcadero to be incorporated (hopefully) in the next release. Drop me an email and I can send you the patches. Publishing them on my blog is planned on the short term.
ReplyDeleteNote: The per monitor dpi works only on recent Windows versions (Win10 1703+). The patches don't address VCL styles and they don't help when you compile with runtime packages.
Great! That's fine, we don't use packages or VCL styles.
ReplyDeleteWe do use (an older version of) the DynamicSkinForm skinning library from http://www.almdev.com/, but we have already performed significant bug-fixes and optimizations on it, and see that we probably have to change it to make it HighDPI compliant too.
almdev.com - Almediadev Home - Delphi Skin VCL, Delphi VCL Style, Delphi Ribbon VCL, Windows 10 Modern Application, Flash control, Effects engine
Attila Kovacs It is still 96 and IMHO that is indeed the correct value. During creation it cannot be known where the control will be shown. It might not even be shown at all after creation, but some time later and on a DPI setting that might even have been changed in between. Think about the forms auto creation in the dpr. The position and thus the target monitor can be changed after creation but before Show.
ReplyDeleteAttila Kovacs That's interesting! Please make that test project and I will try to find out how this has to be handled correctly.
ReplyDeleteLooks like PixelsPerInch is not read anywhere, only written. That is why current code assumes, that form has been designed at 96 DPI.
ReplyDeleteAttila Kovacs I am a bit unsure what you mean with "a 2nd showing form". Usually all of my forms in a project have DFM files. The only idea I get from your steps is to use TForm.Create and add each control by code. Not sure if that is what you are talking about.
ReplyDeleteCould also be the problem only occurs when the IDE is running at a DPI different than 96 dpi (which is something I never do). That's why I asked for precise steps.