|
Replies:
51
-
Last Post:
Mar 31, 2017 11:54 AM
Last Post By: Quentin Correll
|
|
|
Posts:
96
Registered:
5/25/98
|
|
|
The support in Berlin 10.1 for DPI scaling is fundamentally broken.
You can design apps in the IDE at any DPI you like, as long as it is 96.
Your compiled apps will scale correctly at an DPI you like, as long as
it is 96.
I have been working on some really hacky workarounds. However, I still
have problems (especially with some the the Developer Express controls
we use).
I just thought I'd put the question out there to ask how people are
dealing with this. Any hints or workarounds you have found would be
appreciated.
If you are interested, have a look at RSP-14231 and RSP-142912.
J.
|
|
|
Posts:
21
Registered:
1/8/10
|
|
The support in Berlin 10.1 for DPI scaling is fundamentally broken.
...
If you are interested, have a look at RSP-14231 and RSP-142912.
I'm sorry, but neither RSP-142912 is there, nor RSP-14212, RSP-14291 or RSP-14292 are High-DPI issues.
What is the second report you might have meant?
Edited by: Ilya S on Jul 14, 2016 8:23 PM |
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
On 7/14/2016 12:23 PM, Ilya S wrote:
The support in Berlin 10.1 for DPI scaling is fundamentally broken.
...
If you are interested, have a look at RSP-14231 and RSP-142912.
I'm sorry, but neither RSP-142912 is there, nor RSP-14212, RSP-14291 or RSP-14292 are High-DPI issues.
What is the second report you might have meant?
Edited by: Ilya S on Jul 14, 2016 8:23 PM
Sorry about that, fat fingers, here are the two reports I referenced
(there are many, many others, try a search on DPI).
https://quality.embarcadero.com/browse/RSP-14231
https://quality.embarcadero.com/browse/RSP-14912
J. |
|
|
|
|
Posts:
121
Registered:
12/24/04
|
|
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
|
|
|
Posts:
616
Registered:
2/9/07
|
|
Quentin Correll wrote:
I had to be logged in... failed for me when not logged in. |
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
david wrote:
I had to be logged in... failed for me when not logged in.
Correct. Unlike with QualityCentral, tickets in QualityPortal are not publically
viewable without an EDN login.
--
Remy Lebeau (TeamB) |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
david,
Thanks!
--
Q -- XanaNews 1.19.1.372 - 2016-07-19 14:31:51
|
|
|
|
|
Posts:
5
Registered:
4/16/06
|
|
|
Hello,
The system DPI where I am using C++ Builder is 115. To workaround the scaling bug in Berlin I'm calling the above code from every form's OnShow:
Form->ScaleForPPI(96 * Form->Monitor->PixelsPerInch / 115);
This may not work if placed in OnCreate instead in case you are using the Controls' Anchor = akRight property.
Edited by: Konstantin Polyakov on Jul 18, 2016 10:40 AM
|
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
On 7/18/2016 1:41 PM, Konstantin Polyakov wrote:
Hello,
The system DPI where I am using C++ Builder is 115. To workaround the scaling bug in Berlin I'm calling the above code from every form's OnShow:
Form->ScaleForPPI(96 * Form->Monitor->PixelsPerInch / 115);
This may not work if placed in OnCreate instead in case you are using the Controls' Anchor = akRight property.
Edited by: Konstantin Polyakov on Jul 18, 2016 10:40 AM
Hi Konstantin,
I am performing something similar. I do it in an overloaded version of
the form's Loaded procedure.
Our apps use frames a lot, and they are instantiated at run time, and we
then set the frame's parent to a component on a form. We set the
FCurrentPPI value to the design time DPI for all of the controls in the
frame before setting the parent property to avoid incorrect scaling.
We also have problems when a control is aligned anything other than
top,left. Also, the scrollbars on our devex components get scaled
incorrectly, don't have a workaround for that as yet.
What a mess.
J. |
|
|
|
|
Posts:
5
Registered:
4/16/06
|
|
We are using the dynamically frames a lot too, but unlike the previous version of RAD Studio - Seattle - where the the dynamically frames have got the incorrect scaling, the newer Berlin do scales them correctly. Maybe you don't longer need to set up the CurrentPPI property for the frames manually.
But still what a great challenge - to use RAD Studio with the non-standard DPIs. 
Edited by: Konstantin Polyakov on Jul 18, 2016 10:48 PM |
|
|
|
|
Posts:
99
Registered:
10/20/10
|
|
My 2 cents:
In forum 'General' I posted a similar question already in April when I installed Delphi 10.1 Berlin:
https://forums.embarcadero.com/thread.jspa?threadID=210609&tstart=0
[Thread: Delphi10.1 using on 125% Win 10 magnification |https://forums.embarcadero.com/thread.jspa?threadID=210609&tstart=0]
As explained there I am using Delphi10.1 on 125% Win 10 magnification (when developing Delphi programs).
That is much better for my eyes 
125% magnification was fine in all previous Delphi versions up to including XE8, but now I have to use
Form1.Scaleby(80,100);
to make my old programs look 'decent'.
Sometimes that is not enough, so I need to use
ScaleControls(80,100);
In my opinion user should have a possibility to use or not such a new behavior of new Delphi version (by simply checking or unchecking some button).
Otherwise you might have a lot of problems with old programs - probably I will migrate back to good old Delphi XE8, which is good enough for me.
A. |
|
|
|
|
Posts:
314
Registered:
5/16/97
|
|
|
I have made some apps with Hi-DPI settings without trouble.
You mentioned Frames, but those have been fixed.
As a rule, you are supposed to leave PixelsPerInch property at 96 when designing the form. Then when it is DPI aware the size of everything (except bitmaps) will change automatically.
|
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
On 7/25/2016 5:49 PM, Douglas Rudd wrote:
I have made some apps with Hi-DPI settings without trouble.
You mentioned Frames, but those have been fixed.
As a rule, you are supposed to leave PixelsPerInch property at 96 when designing the form. Then when it is DPI aware the size of everything (except bitmaps) will change automatically.
The problem occurs when you don't follow the "rule", i.e. when you run
the IDE at any DPI except 96, which I do.
By design, the DPI used at design time is supposed to be taken into
account when scaling at run time. But in Berlin 10.1 the RTL is coded
such that the design time time DPI setting is not used when scaling, a
hard coded value of 96 is used instead.
J. |
|
|
|
|
Posts:
99
Registered:
10/20/10
|
|
By design, the DPI used at design time is supposed to be taken into
account when scaling at run time. But in Berlin 10.1 the RTL is coded
such that the design time time DPI setting is not used when scaling, a
hard coded value of 96 is used instead.
Agree 100%.
I think that is the problem of Berlin 10.1.
A. |
|
|
|
|
Posts:
314
Registered:
5/16/97
|
|
|
96 dpi is "normal", base", "standard".
Windows uses 96 dpi as the base for calculating whether it should increase or decrease size.
I have a Windows 10 Hi-DPI monitor that is set in Windows display settings at 200%. Making a form that has its PixelsPerInch property set to 96 and options set to "Enable High-DPI" will display at a normal size on the screen. The same size on the screen as when you unchecked "Enable High-DPI".
Windows sizes the window by dividing the current dpi by 96. So if you set it initially to something other than 96 you are going to mess things up.
|
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
On 7/26/2016 3:12 PM, Douglas Rudd wrote:
96 dpi is "normal", base", "standard".
Windows uses 96 dpi as the base for calculating whether it should increase or decrease size.
Sorry, if you declare your program as DPI-aware to Windows, then its the
code in your program that is responsible for scaling. This is why there
is a whack of code in the Delphi RTL that is supposed to do this, except
its broken.
I have a Windows 10 Hi-DPI monitor that is set in Windows display settings at 200%. Making a form that has its PixelsPerInch property set to 96 and options set to "Enable High-DPI" will display at a normal size on the screen. The same size on the screen as when you unchecked "Enable High-DPI".
The form's pixelsperinch is the design-time DPI. And yes, if you use 96
DPI at design time, then the form will be scaled correctly by the Delphi
run-time library. (Mostly, there are other scaling bugs in the Delphi
RTL, but that's another story.
If you do not tell Windows that your code id dpi-aware, then Windows
will scale it for you by scaling a rasterized image of your form. This
will almost certainly result in blurry text, which is why its better to
have your program do the scaling.
Windows sizes the window by dividing the current dpi by 96. So if you set it initially to something other than 96 you are going to mess things up.
Windows only scales non dpi-aware programs. And you get the blurry text
effect.
Delphi is intended to allow you to design at any DPI - the design time
DPI is stored in the PIXELSPERINCH value of the form.
At run time, the Screen.Monitor[x].PixelsPerinch value is the runtime
DPI value. Forms are supposed to be scaled based on the ratio of design
time to run time DPI. Again, windows does not do this, its the Delphi
RTL that is responsible for this and it is currently broken.
J. |
|
|
|
|
Posts:
314
Registered:
5/16/97
|
|
Sorry, if you declare your program as DPI-aware to Windows, then its the
code in your program that is responsible for scaling. This is why there
is a whack of code in the Delphi RTL that is supposed to do this, except
its broken.
What do you mean "your program that is responsible for scaling"? I can make a program with components with no code and it comes out the correct size when dpi-aware.
The form's pixelsperinch is the design-time DPI. And yes, if you use 96
DPI at design time, then the form will be scaled correctly by the Delphi
run-time library. (Mostly, there are other scaling bugs in the Delphi
RTL, but that's another story.
You mean the form will scale correctly when dpi-aware or not dpi-aware?
If you do not tell Windows that your code id dpi-aware, then Windows
will scale it for you by scaling a rasterized image of your form. This
will almost certainly result in blurry text, which is why its better to
have your program do the scaling.
Yes, it will scale a rasterized image when not dpi-aware. But why do I have to put code in the program to scale the form when I set to dpi-aware?
Windows only scales non dpi-aware programs. And you get the blurry text
effect.
Well, it depends what you mean by "scales". The OS is scaling every window on the screen when you have the slider in the OS display settings set to something other than 100%
Delphi is intended to allow you to design at any DPI - the design time
DPI is stored in the PIXELSPERINCH value of the form.
Is that what you are doing? Trying to change the size of the form on the screen by changing the PIXELSPERINCH value of the form?
At run time, the Screen.Monitor[x].PixelsPerinch value is the runtime
DPI value. Forms are supposed to be scaled based on the ratio of design
time to run time DPI. Again, windows does not do this, its the Delphi
RTL that is responsible for this and it is currently broken.
On your forms, you never said what exactly happens when set to dpi-aware. Do they come out too small or too big? |
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
On 7/26/2016 9:04 PM, Douglas Rudd wrote:
Sorry, if you declare your program as DPI-aware to Windows, then its the
code in your program that is responsible for scaling. This is why there
is a whack of code in the Delphi RTL that is supposed to do this, except
its broken.
What do you mean "your program that is responsible for scaling"? I can make a program with components with no code and it comes out the correct size when dpi-aware.
I mean that the Windows OS itself does not do the scaling for
DPI-aware.programs. For programs developed using Delphi, its the Delphi
run time library that implements scaling.
The form's pixelsperinch is the design-time DPI. And yes, if you use 96
DPI at design time, then the form will be scaled correctly by the Delphi
run-time library. (Mostly, there are other scaling bugs in the Delphi
RTL, but that's another story.
You mean the form will scale correctly when dpi-aware or not dpi-aware?
The form scales correctly only if it is designed at 96 DPI, and you
specify dpi-aware. If you do not specify that the program is DPI-aware,
Windows will scale forms if the Windows DPI setting is > 96 DPI on
Windows 10, or > 120 on Windows 7. The results may not be acceptable
(blurry text) depending on the scale factor and the monitors physical
DPI. If you design at 120 DPI, the form does not scale correctly when
set to be DPI-aware or not, and gets the blurry text type scaling when
non-DPI aware.
BTW The IDE itself has many problems when run on a system, where the
display scaling is anything other than 96 DPI.
If you do not tell Windows that your code id dpi-aware, then Windows
will scale it for you by scaling a rasterized image of your form. This
will almost certainly result in blurry text, which is why its better to
have your program do the scaling.
Yes, it will scale a rasterized image when not dpi-aware. But why do I have to put code in the program to scale the form when I set to dpi-aware?
You shouldn't need to, the Delphi RTL is supposed to take care of it for
you, but because its broken, you will need to include some workaround
code until Delphi is fixed. (There are some issues that I don't know how
to deal with even so).
Windows only scales non dpi-aware programs. And you get the blurry text
effect.
Well, it depends what you mean by "scales". The OS is scaling every window on the screen when you have the slider in the OS display settings set to something other than 100%
No, as I explained, if the program declares itself dpi-aware, it is the
program that does the scaling. In the case of Delphi, its the Delphi
RTL. The OS itself only applies rasterized scaling for non DPI-aware
programs.
Delphi is intended to allow you to design at any DPI - the design time
DPI is stored in the PIXELSPERINCH value of the form.
Is that what you are doing? Trying to change the size of the form on the screen by changing the PIXELSPERINCH value of the form?
No. I am designing forms in the IDE on a development machine with the
Windows DPI setting a 120 DPI. The IDE sets the PIXELSPERINCH property
based on the DPI setting of the development machine.
Historically, the Delphi RTL used this in conjunction with the
Screen.PixelsPerInch property (the run time DPI setting on the users
machine) to do the scaling. They changed the RTL (in Seattle I think) to
handle per-monitor DPI scaling, and totally reworked the scaling code.
They have introduced a number of errors in the rewrite. Search for DPI
in the quality portal and you'll get about 50 issues. Not all of which
are fixed.
At run time, the Screen.Monitor[x].PixelsPerinch value is the runtime
DPI value. Forms are supposed to be scaled based on the ratio of design
time to run time DPI. Again, windows does not do this, its the Delphi
RTL that is responsible for this and it is currently broken.
On your forms, you never said what exactly happens when set to dpi-aware. Do they come out too small or too big?
If you set your program to be DPI aware, Windows does not apply
rasterized scaling. The Delphi RTL assumes your forms were designed at
96, so it scales them up if the monitor (at run time) has a scaling
higher than 96. So at 120 DPI for example, the forms are scaled up by
25%, even though they were designed at 120 DPI, so they end up being 25%
too big.
J. |
|
|
|
|
Posts:
99
Registered:
10/20/10
|
|
If you set your program to be DPI aware, Windows does not apply
rasterized scaling. The Delphi RTL assumes your forms were designed at
96, so it scales them up if the monitor (at run time) has a scaling
higher than 96. So at 120 DPI for example, the forms are scaled up by
25%, even though they were designed at 120 DPI, so they end up being 25%
too big.
Exactly!
I encountered the same problem:
I am using machine with the Windows DPI setting of 120 DPI for several years.
Never had problems but a lot of problems now with 10.1 Berlin:
Now when program developed on 120 DPI is ALSO USED on 120 DPI the forms and other components
(buttons, speedbuttons, but NOT bitmaps) are resized for:
=120% * 120% = 144% - everything is too big.
But even more: It seems that text in components like labels and checkboxes is resized even more
(or text is resized differently?).
The result is that text is overwriting the size of component although when designing it fits just fine.
I really hope that this will be fixed ASAP and give us as an update. |
|
|
|
|
Posts:
314
Registered:
5/16/97
|
|
If you set your program to be DPI aware, Windows does not apply
rasterized scaling. The Delphi RTL assumes your forms were designed at
96, so it scales them up if the monitor (at run time) has a scaling
higher than 96. So at 120 DPI for example, the forms are scaled up by
25%, even though they were designed at 120 DPI, so they end up being 25%
too big.
It still sounds like you are setting the form property to something other than 96. That's not the way it is supposed to work. (even if in the old days you could control the size of the form by changing pixelsperinch. That's not the same as the new Windows dpi-aware)
You say it works if you set to 96 and set dpi-aware. Why not use that?
|
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
On 7/27/2016 9:55 AM, Douglas Rudd wrote:
If you set your program to be DPI aware, Windows does not apply
rasterized scaling. The Delphi RTL assumes your forms were designed at
96, so it scales them up if the monitor (at run time) has a scaling
higher than 96. So at 120 DPI for example, the forms are scaled up by
25%, even though they were designed at 120 DPI, so they end up being 25%
too big.
It still sounds like you are setting the form property to something other than 96. That's not the way it is supposed to work. (even if in the old days you could control the size of the form by changing pixelsperinch. That's not the same as the new Windows dpi-aware)
You say it works if you set to 96 and set dpi-aware. Why not use that?
Sorry, that is exactly how it is supposed to work. The intent of the
Delphi IDE form designer is that you can design at any DPI you like, and
the forms will be scaled appropriately at the DPI on the users system.
The notion that you must design at 96 DPI is simply wrong. (Otherwise
the FORM.PIXELSPERINCH property would not be required at all).
If you have a high DPI (4K) monitor, using 96 DPI at design time is
going to be problematic for most users, because forms / controls will be
too tiny to see comfortably.
I've been using the Delphi IDE on a system set to 120 DPI for many, many
years. Its not until I upgraded to Berlin that I encountered these
problems. In fact, one of the main reasons I upgraded was the claimed
support for high-dpi awareness with Windows 10. Turns out both the IDE
and run time library are riddled with DPI-aware related bugs.
YMMV
J. |
|
|
|
|
Posts:
683
Registered:
3/3/01
|
|
"John Furlong" wrote on Wed, 27 Jul 2016 08:31:47 -0700:
Turns out both the IDE
and run time library are riddled with DPI-aware related bugs.
Seattle's original release wasn't overly bad but was not thorough
enough. Then the first update to Seattle broke a lot. I have a ton of
my own code to make dpi-aware work for my application. I have not
upgraded to 10.1 but two things tell me it will be a pain -- 1., they
said that they improved DPI aware stuff, which means they probably
broke a lot again, and that my current fixes won't work, and 2., they
removed the ability to use class helpers to get into some of the
necessary private fields in order to fix their bugs without editing
the vcl source. Not looking forward to it!
The only way we will get usable DPI awareness is if the people who
develop Delphi are required to use it in mixed-dpi environments
themselves. It is obvious their test cases are simplistic.
They should be required to run the IDE on a 4K monitor and then move
it back and forth from a 96-dpi monitor on the same desktop, over and
over again.
--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com |
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
On 7/28/2016 8:55 AM, Brandon Staggs wrote:
"John Furlong" wrote on Wed, 27 Jul 2016 08:31:47 -0700:
Turns out both the IDE
and run time library are riddled with DPI-aware related bugs.
<snip>
The only way we will get usable DPI awareness is if the people who
develop Delphi are required to use it in mixed-dpi environments
themselves. It is obvious their test cases are simplistic.
+1000
They should be required to run the IDE on a 4K monitor and then move
it back and forth from a 96-dpi monitor on the same desktop, over and
over again.
Yep!
J. |
|
|
|
|
Posts:
314
Registered:
5/16/97
|
|
Sorry, that is exactly how it is supposed to work. The intent of the
Delphi IDE form designer is that you can design at any DPI you like, and
the forms will be scaled appropriately at the DPI on the users system.
If you wanted it universal for users you would design it at 96. That way the size would come out normal (according to their text scaling settings) no matter whether the user had high DPI monitor or were using old Windows XP on a 96 monitor. I tried it and it worked.
The Delphi RTL assumes your forms were designed at
96, so it scales them up if the monitor (at run time) has a scaling
higher than 96. So at 120 DPI for example, the forms are scaled up by
25%, even though they were designed at 120 DPI, so they end up being 25%
too big.
If you want your form window larger than normal, like if you were making an app for people with cataracts, you want the form to be larger than normal. Which you would always have done by changing the PixelsPerInch. It does exactly the same thing now. You just said above that if you set PixelsPerInch to 120 then the form comes out 25% bigger than normal. On both dpi-aware and not. Which is what it is supposed to do.
You are still saying, "my monitor is 120 DPI, therefore I should put 120 in the PixelsPerInch property of the form."
If you have a high DPI (4K) monitor, using 96 DPI at design time is
going to be problematic for most users, because forms / controls will be
too tiny to see comfortably.
I haven't seen this.
Everybody is talking about this but where is an example project to show? Or example instructions? Or a description of what they want it to look like?
This is my app shown with and without hi-dpi-aware.
http://i-logic.com/temp/ScreenShot1.png
The one on the left is non-dpi-aware and has blurry text as expected. The one on the right is dpi-aware and has sharp text as expected.
This was designed and displayed on a 192 DPI monitor OS display settings set to 200%. It also looks normal on Windows XP 96 dpi monitor set to 100% |
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
OK, I will have one last kick at the can.
On 7/28/2016 1:33 PM, Douglas Rudd wrote:
Sorry, that is exactly how it is supposed to work. The intent of the
Delphi IDE form designer is that you can design at any DPI you like, and
the forms will be scaled appropriately at the DPI on the users system.
If you wanted it universal for users you would design it at 96. That way the size would come out normal (according to their text scaling settings) no matter whether the user had high DPI monitor or were using old Windows XP on a 96 monitor. I tried it and it worked.
If I design at 120 DPI. And the user runs it on a device at 120 DPI, it
should be displayed on the users system at the same size as design time.
This is not what happens, on the users system the RTL will scale it up
by 25%. I can't understand why this seem so hard to accept.
The Delphi RTL assumes your forms were designed at
96, so it scales them up if the monitor (at run time) has a scaling
higher than 96. So at 120 DPI for example, the forms are scaled up by
25%, even though they were designed at 120 DPI, so they end up being 25%
too big.
If you want your form window larger than normal, like if you were making an app for people with cataracts, you want the form to be larger than normal. Which you would always have done by changing the PixelsPerInch. It does exactly the same thing now. You just said above that if you set PixelsPerInch to 120 then the form comes out 25% bigger than normal. On both dpi-aware and not. Which is what it is supposed to do.
You are still saying, "my monitor is 120 DPI, therefore I should put 120 in the PixelsPerInch property of the form."
Yep. This is what the IDE does when you create a new form, thus it
allows you to design at the DPI setting of your system.
If you have a high DPI (4K) monitor, using 96 DPI at design time is
going to be problematic for most users, because forms / controls will be
too tiny to see comfortably.
I haven't seen this.
I meant the users of the IDE, not end users. If you set your 192 DPI
monitor to scaling of 100%. Text will appear to be half the size of a
"normal" 96 DPI monitor.
If you haven't already done so, fix the IDE's broken manifest by
specifying an external manifest that declares the IDE as dpi-aware
(otherwise you'll get fuzzy text in the IDE). Now, run the IDE and
create a new form and add some controls. You'll get tiny controls with
tiny text that is very hard to see unless you have really excellent vision.
Everybody is talking about this but where is an example project to show? Or example instructions? Or a description of what they want it to look like?
This is my app shown with and without hi-dpi-aware.
http://i-logic.com/temp/ScreenShot1.png
The one on the left is non-dpi-aware and has blurry text as expected. The one on the right is dpi-aware and has sharp text as expected.
This was designed and displayed on a 192 DPI monitor OS display settings set to 200%. It also looks normal on Windows XP 96 dpi monitor set to 100%
|
|
|
|
|
Posts:
99
Registered:
10/20/10
|
|
|
Anyone knows: Is this fixed in Berlin Update 1?
Thanks.
|
|
|
|
|
Posts:
121
Registered:
12/24/04
|
|
|
|
|
|
Posts:
32
Registered:
9/23/99
|
|
It's still unfixed and I've found the blurriness of the text a major
headache (almost literally). However, with a fairly simple workaround, I
have been able to force the IDE to be DPIAware (without reducing the
system font sizes which isn't an option on high res. screens).
Sample of blurriness on my Microsoft Surface Pro 3 laptop with OS fonts
set to 150%: http://www.angusj.com/temp/IDE_1.png
The steps required to enforce DPI awareness:
1. Add a simple manifest file into the Delphi 10.1 'bin' folder:
http://www.angusj.com/temp/bds.exe.manifest
This is a simple 2KB XML text file that's a very minor modification of
the manifest in resource in bds.exe (I just changed 2 lines).
2. Force the OS to prefer external manifest files if present.
Open regedit.exe and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
Add the a new DWORD key "PreferExternalManifest" and set it to 1.
(See https://support.microsoft.com/en-au/kb/912949 for more info on this.)
This is what the text in the IDE looks like:
http://www.angusj.com/temp/IDE_1.png
It may not look like there's a lot of difference at first blush, but it
really is a huge improvement. (I no longer get tired eyes after a few
minutes that I was getting with the unmodified IDE).
That's the essentials but you also need to tweak font sizes in the IDE
(to make them bigger) and fortunately that's not too hard.
Here's a link to my open source design-time package that does that:
http://www.angusj.com/temp/fancyshortcuts.zip
Non-blurry text: See http://www.angusj.com/temp/IDE_2.png
Tweaked fonts in the IDE: See http://www.angusj.com/temp/IDE_4.png
There's no formal documentation yet but the source code is heavily
commented ready to use. Just compile and install. And then you can tweak
it later to meet your own needs.
I've included several (almost essential) keyboard shortcuts based on
GExpert's shortcuts:
1. Quick Searching: Ctrl+Alt+Up and Ctrl+Alt+Down navigates to previous
or following occurrences of the word under the cursor (with
highlighting). See http://www.angusj.com/temp/IDE_2.png
2. Ctrl+G to popup a Procedure/Function navigating dialog. (The Navigate
toolbar at the top of the editor is too cumbersome and mouse-bound to be
useful.) See http://www.angusj.com/temp/IDE_6.png
3. Ctrl+Shift+A to ANSI chart. See http://www.angusj.com/temp/IDE_5.png
4. Ctrl+Shift+C to get Calc.exe. (The code for this can easily be copied
to access any other external utility you want at your fingertips in the
IDE.)
Unfortunately, the IDE isn't without issues once it's been forced IDE
aware. For example the Find in Files dialog gets chopped of at the
bottom so you can't see the Search / Cancel buttons (see
http://www.angusj.com/temp/IDE_3.png). Apart from that, any other issues
are minor relative to the huge improvement in no longer having blurred text.
Finally, the 'Welcome Page' in the IDE needs tweaking too. Here's a link
to a modified styles.css file that does that:
Put this in Welcomepage\css folder.
Hope that helps
Welcomepage\css\ |
|
|
|
|
Posts:
32
Registered:
9/23/99
|
|
|
|
|
|
Posts:
32
Registered:
9/23/99
|
|
It's still unfixed and I've found the blurriness of the text a major
headache (almost literally). However, with a fairly simple workaround, I
have been able to force the IDE to be DPIAware (without reducing the
system font sizes which isn't an option on high res. screens).
Sample of blurriness on my Microsoft Surface Pro 3 laptop with OS fonts
set to 150%: http://www.angusj.com/temp/IDE_1.png
The steps required to enforce DPI awareness:
1. Add a simple manifest file into the Delphi 10.1 'bin' folder:
http://www.angusj.com/temp/bds.exe.manifest
This is a simple 2KB XML text file that's a very minor modification of
the manifest in resource in bds.exe (I just changed 2 lines).
2. Force the OS to prefer external manifest files if present.
Open regedit.exe and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
Add the a new DWORD key "PreferExternalManifest" and set it to 1.
(See https://support.microsoft.com/en-au/kb/912949 for more info on this.)
This is what the text in the IDE looks like:
http://www.angusj.com/temp/IDE_2.png
It may not look like there's a lot of difference at first blush, but it
really is a huge improvement. (I no longer get tired eyes after a few
minutes that I was getting with the unmodified IDE).
That's the essentials but you also need to tweak font sizes in the IDE
(to make them bigger) and fortunately that's not too hard.
Here's a link to my open source design-time package that does that:
http://www.angusj.com/temp/fancyshortcuts.zip
Non-blurry text: See http://www.angusj.com/temp/IDE_2.png
Tweaked fonts in the IDE: See http://www.angusj.com/temp/IDE_4.png
There's no formal documentation yet but the source code is heavily
commented ready to use. Just compile and install. And then you can tweak
it later to meet your own needs.
I've included several (almost essential) keyboard shortcuts based on
GExpert's shortcuts:
1. Quick Searching: Ctrl+Alt+Up and Ctrl+Alt+Down navigates to previous
or following occurrences of the word under the cursor (with
highlighting). See http://www.angusj.com/temp/IDE_2.png
2. Ctrl+G to popup a Procedure/Function navigating dialog. (The Navigate
toolbar at the top of the editor is too cumbersome and mouse-bound to be
useful.) See http://www.angusj.com/temp/IDE_6.png
3. Ctrl+Shift+A to ANSI chart. See http://www.angusj.com/temp/IDE_5.png
4. Ctrl+Shift+C to get Calc.exe. (The code for this can easily be copied
to access any other external utility you want at your fingertips in the
IDE.)
Unfortunately, the IDE isn't without issues once it's been forced IDE
aware. For example the Find in Files dialog gets chopped of at the
bottom so you can't see the Search / Cancel buttons (see
http://www.angusj.com/temp/IDE_3.png). Apart from that, any other issues
are minor relative to the huge improvement in no longer having blurred text.
Finally, the 'Welcome Page' in the IDE needs tweaking too. Here's a link
to a modified styles.css file that does that:
Put this in Welcomepage\css folder.
Hope that helps
Welcomepage\css\ |
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
On 9/19/2016 12:07 PM, Andrej Mrvar wrote:
Anyone knows: Is this fixed in Berlin Update 1?
Thanks.
Nope.
In Berlin (update 1 or no), the IDE, and any Delphi apps you generated
with it will run correctly at any DPI setting you like, as long as it is 96.
For me, this is compounded by the fact that the DevEx components we use
are also unable to deal correctly with non 96 DPI settings, and they
don't seem inclined to do anything about it.
<mutter, mutter, grumble>
J. |
|
|
|
|
Posts:
99
Registered:
10/20/10
|
|
|
Then Berlin is for me also just a waste of money.
I will have to stay with good old XE8.
|
|
|
|
|
Posts:
121
Registered:
12/24/04
|
|
Then Berlin is for me also just a waste of money.
I will have to stay with good old XE8.
Let's wait for Delphi 18.0 Kabul... |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Ralf Stocker wrote:
Then Berlin is for me also just a waste of money.
I will have to stay with good old XE8.
Let's wait for Delphi 18.0 Kabul...
Only after 10.2 Bottrop.
--
Rudy Velthuis http://www.rvelthuis.de
"I'm not into working out. My philosophy: No pain, no pain."
-- Carol Leifer. |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 23.09.2016 um 08:31 schrieb Rudy Velthuis (TeamB):
Ralf Stocker wrote:
Then Berlin is for me also just a waste of money.
I will have to stay with good old XE8.
Let's wait for Delphi 18.0 Kabul...
Only after 10.2 Bottrop.
Means: never.
Greetings
Markus |
|
|
|
|
Posts:
121
Registered:
12/24/04
|
|
Am 23.09.2016 um 08:31 schrieb Rudy Velthuis (TeamB):
Ralf Stocker wrote:
Then Berlin is for me also just a waste of money.
I will have to stay with good old XE8.
Let's wait for Delphi 18.0 Kabul...
Only after 10.2 Bottrop.
Means: never.
Greetings
Markus
No, means, when Delphi is able to handle High DPI. |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Markus Humm wrote:
Am 23.09.2016 um 08:31 schrieb Rudy Velthuis (TeamB):
Ralf Stocker wrote:
Then Berlin is for me also just a waste of money.
I will have to stay with good old XE8.
Let's wait for Delphi 18.0 Kabul...
Only after 10.2 Bottrop.
Means: never.
You're just jealous you didn't have the idea first. <g>
--
Rudy Velthuis http://www.rvelthuis.de
"This is not a novel to be tossed aside lightly. It should be
thrown with great force." -- Book review by Dorothy Parker |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 27.09.2016 um 11:18 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:
Am 23.09.2016 um 08:31 schrieb Rudy Velthuis (TeamB):
Ralf Stocker wrote:
Then Berlin is for me also just a waste of money.
I will have to stay with good old XE8.
Let's wait for Delphi 18.0 Kabul...
Only after 10.2 Bottrop.
Means: never.
You're just jealous you didn't have the idea first. <g>
No I'm not.
I'm rather annoyed by you persiistently asking for naming the product
after a minor city nearly nobody outside Germany even knows.
What would be the name of the beta matching Bottrop?
Does it have a Tower Bridge, Monsters, a nice TV Tower or other landmarks?
Greetings
Markus |
|
|
|
|
Posts:
397
Registered:
6/28/03
|
|
Markus Humm wrote:
What would be the name of the beta matching Bottrop?
"Dentist"
--
Cheers,
Van
"Good judgment comes from experience, and a lot of that comes from bad
judgment." - Will Rogers |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Markus Humm wrote:
You're just jealous you didn't have the idea first. <g>
No I'm not.
That is what anyone would say. <g>
I'm rather annoyed by you persiistently asking for naming the product
after a minor city nearly nobody outside Germany even knows.
I'm shocked! I'm flabbergasted, I tell you. That knocks me off my feet.
You seem to confuse Bottrop with Bielefeld.
https://en.wikipedia.org/wiki/Bielefeld_Conspiracy
Take a look at Apple. They often name entire OSes afer places or
mountain ridges no one outside the US knows. Or do you know anyone who
has ever been in, say, Snow Leopard?
--
Rudy Velthuis http://www.rvelthuis.de
"Money often costs too much."
-- Ralph Waldo Emerson |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Markus Humm wrote:
I'm rather annoyed by you persiistently asking for naming the product
after a minor city nearly nobody outside Germany even knows.
What would be the name of the beta matching Bottrop?
"Tetrahedron", of course. Or "Movie Park". Or "Alpine Center".
https://en.wikipedia.org/wiki/Tetrahedron_in_Bottrop
https://en.wikipedia.org/wiki/Movie_Park_Germany
http://alpincenter.com/bottrop/en/latest/
--
Rudy Velthuis http://www.rvelthuis.de
"If you want a girlfriend, avoid working in the computer games
industry like the plague. If you work seven days a week, 15
hours a day for almost two years, with barely enough time for
a pint, you have no time whatsoever for relationships. Plus
computer-games makers are regarded as being about as hip and
cool as abattoir workers." -- Toby Gard, creator of Lara Croft. |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
Andrej,
| I will have to stay with good old XE8.
That's also what I have done.
--
Q -- XanaNews 1.19.1.372 - 2016-09-24 11:26:38
|
|
|
|
|
Posts:
43
Registered:
2/14/00
|
|
We had issues in Seattle going from XE 5. Everything looked horrible using medium fonts.
Berlin seems to have completely addressed the issue for us, with some minor exceptions.
We do design at 96 DPI.
Dan
On 9/19/2016 12:07 PM, Andrej Mrvar wrote:
Anyone knows: Is this fixed in Berlin Update 1?
Thanks.
Nope.
In Berlin (update 1 or no), the IDE, and any Delphi apps you generated
with it will run correctly at any DPI setting you like, as long as it is 96.
For me, this is compounded by the fact that the DevEx components we use
are also unable to deal correctly with non 96 DPI settings, and they
don't seem inclined to do anything about it.
<mutter, mutter, grumble>
J. |
|
|
|
|
Posts:
70
Registered:
10/16/00
|
|
Hi,
This is my app shown with and without hi-dpi-aware.
http://i-logic.com/temp/ScreenShot1.png
The one on the left is non-dpi-aware and has blurry text as expected. The one on the right is dpi-aware and has sharp text as expected.
This was designed and displayed on a 192 DPI monitor OS display settings set to 200%. It also looks normal on Windows XP 96 dpi monitor set to 100%
Thanks for this. One question immediately comes to mind: how do you deal with image lists?
I notice that left and right some (some?) different images for the same command (print, save etc.)
In OSX / iOS you simply define an image.png and image@2x.png
Is there something similar in Delphi where I use image lists?
Gerrit Beuze
ModelMaker Tools |
|
|
|
|
Posts:
99
Registered:
10/20/10
|
|
|
Anyone maybe knows: Is this problem solved in Tokyo 10.2?
|
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 29.03.2017 um 13:14 schrieb Andrej Mrvar:
Anyone maybe knows: Is this problem solved in Tokyo 10.2?
They did something to VCL DPI issues in Tokyo, but if it is satisfying
or not I can't tell.
Greetings
Markus |
|
|
|
|
Posts:
156
Registered:
10/26/99
|
|
Am 29.03.2017 um 13:14 schrieb Andrej Mrvar:
Anyone maybe knows: Is this problem solved in Tokyo 10.2?
They did something to VCL DPI issues in Tokyo, but if it is satisfying
or not I can't tell.
I haven't gotten around to research the issue.
It probably works ok as long as you don't have multi-display setups with differing DPI ratios per display.
It seems that even MS own tools have problems with that.
--
http://plus.lars.fosdal.com
Delphi Developers Google+ Community: https://plus.google.com/communities/103113685381486591754 (8500+ members) |
|
|
|
|
Posts:
39
Registered:
9/28/99
|
|
|
|
|
|
Posts:
99
Registered:
10/20/10
|
|
Yes, I am using VCL.
It seems I will stay with XE8
Thanks. |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
Andrej,
| It seems I will stay with XE8
I made that decision for myself a LONG time ago!!! <g>
--
Q -- XanaNews 1.19.1.372 - 2017-03-31 11:54:50 |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 30.03.2017 um 14:16 schrieb Achim Kalwa:
Hello,
Andrej Mrvar wrote:
Anyone maybe knows: Is this problem solved in Tokyo 10.2?
If you are talking about VCL:
It is improved, but not solved.
Ok, so what is improved then?
Greetings
Markus |
|
|
|
Legend
|
|
Helpful Answer
(5 pts)
|
|
Correct Answer
(10 pts)
|
|
Connect with Us