Forms editor scaling changes across platforms

[kupferstecher]

Does a compiled Exe have the original size for you on different dpi-scalings? So design behaviour (always scaling) and runtime behaviour (scaling only if enabled) is different?

[wp]

I'll have to check the unscaled behavior tomorrow. Although I don't understand why somebody might want to turn scaling off...

It appears dangerous to edit the same project on systems with different dpis.

I've done it many times, no problems. (But of course, i always have LCLScaling enabled).

[VTwin]

My initial test shows that an application compiled on Win 7 at 96 dpi does not display correctly on Win 7 at 144. That is with DPI options on. Happy to be proved wrong.

I note also that compiling a form designed at 96 requires a change, even a small one, to a form to get it to recompile and display correctly at 144.

[VTwin]

I'll have to check the unscaled behavior tomorrow. Although I don't understand why somebody might want to turn scaling off...

It appears dangerous to edit the same project on systems with different dpis.

I've done it many times, no problems. (But of course, i always have LCLScaling enabled).

Fair enough, that is good news. It only happened to me when I unchecked the "Force DPI scaling" option. Hopefully it is safe otherwise.

[wp]

My initial test shows that an application compiled on Win 7 at 96 dpi does not display correctly on Win 7 at 144. That is with DPI options on.

You mean: you compile an application on Win/96dpi, copy the exe to a system at 144dpi, and it does not scale correctly although high-dpi was active during compilation?

I just re-checked this procedure with the demo that I posted earlier in this thread. No problem, the copied form looks exactly like the one compiled on the 144dpi system.

[wp]

I note also that compiling on Win 7 at 144 requires a change, even a small one, to a form to get it to recompile and display correctly at 144.

I don't think that this is essential: with the tiny change a new lfm is written on the 144dpi system and it contains the new dpi value. When this file is opened on the 144dpi system next time, no conversions have to be executed because the dpi values are matching. Without a change the lfm is not written to disk at all even if you changed code in the pas file, but this means that the lfm still contains the old dpi value. When the project is opened the next time on the 144 dpi system scaling should occur due to the different dpi values.

[VTwin]

You mean: you compile an application on Win/96dpi, copy the exe to a system at 144dpi, and it does not scale correctly although high-dpi was active during compilation?

I just re-checked this procedure with the demo that I posted earlier in this thread. No problem, the copied form looks exactly like the one compiled on the 144dpi system.

That is what I did. I have some controls, PaintBoxes, sized at 20x20 in 96 dpi. If I compile it in Windows 96 dpi, and then run it in 144 dpi, the PaintBoxes display as 20x20. If I recompile in Windows at 144, they rescale to 30x30.

All high DPI settings on.

[VTwin]

I note also that compiling on Win 7 at 144 requires a change, even a small one, to a form to get it to recompile and display correctly at 144.

I don't think that this is essential: with the tiny change a new lfm is written on the 144dpi system and it contains the new dpi value. When this file is opened on the 144dpi system next time, no conversions have to be executed because the dpi values are matching. Without a change the lfm is not written to disk at all even if you changed code in the pas file, but this means that the lfm still contains the old dpi value. When the project is opened the next time on the 144 dpi system scaling should occur due to the different dpi values.

I'm not clear on that. The control sizes were definitely not changing unless I made a small change in the form designer. I am speaking of designing the form on a Mac at 96, and trying to recompile on Windows at 144. It happened every time.

[VTwin]

I honestly do not know what to do. Ignore DPI, release for multiple DPIs? I would appreciate guidance.

[kupferstecher]

Although I don't understand why somebody might want to turn scaling off...

I can think of a list of reasons.
- Backward compatibility
- Usage of components that don't support scaling
- Custom components that rely on predefined dimensions
- Project stage, where scaling is not tested on different values yet, i.e. to guarantee a working application on different OS settings.

Because of the first and last point in my opinion the scaling should be off by default. I'd compare the scaling to i18n. It's an additional feature of the application that needs to be cared about on development. You couldn't say it always works out of the box.

--
I just tried to make a demo application and I'm even more confused now. When scaling settings are off, the application will still scale, both on design time and run time. But I have an existing application (some years old), that behaves differently. On designtime it will scale, but once compiled it will keep its original settings on any scaling factor of the OS*. The Project settings are the same ("scaled value" and "dpi aware" in the lpi-files both are disabled). I can't find what is different...*2

*Edit: Some controls are scaled as well, e.g. check boxes, combo boxes.

*2:Just checked again. If I enable scaling (Laz 2.0.2) for the "old" program, compile and disable it afterwards again, it always scales, so it changes behaviour. If I open it with Laz 1.8.0 again, the original behaviour, scaling only at design time works again, also if compiled with Laz 2.0.2.

There's obviously a bug. Should I also check with current trunk? What is the intended behaviour?

[wp]

Of course, with scaling to a higher resolution, say 150% all dimensions must increase by this factor. This is way scaling is done after all. Suppose you have a 26" monitor with, say 2000x1000 pixels (numbers selected for simplicity of calculation). Then you go to a "Super real-life retina display", same size but with 3000x1500 pixels (i.e. 150% more in each dimension. Without scaling a form of 2000x1000 pixels would fill the entire screen on the 2000x1000 monitor, but only part of it on the 3000x1500 model.

If scaling is activated, then yes. But seems Lazarus also scales the design time form if scaling is disabled in the settings (using Laz 2.0.2). I.e. if I design a form under Win 7 125% with disabled scaling and I change dpi-settings of Windows to 100% then the form will be much smaller. On the same time a form designed and compiled under a dpi-settings will stay in the original size no matter under which dpi-setting the Exe is run.
The paradigm 'Write once, compile everywhere' is broken for disabled dpi scaling (and backward compatibility as well). Can someone comment on that? I may be wrong as I'm not familiar with dpi-scaling yet.

I played with deactivated LCLscaling myself and must say that your observations are correct. Very confusing. I contacted Ondrej Pokorny who wrote these routines for the LCL.

[kupferstecher]

Hello wp,

thanks for testing.
I played around, again. On Lazarus 1.8.0 with disabled scaling it worked as I would expect it. No scaling in the design time and no scaling on runtime.

[wp]

Are Laz 1.8.2 and 1.8.4 behaving like 1.8.0? Can you try to find out which revision in trunk broke it?

[kupferstecher]

Then I have to install them. With fpcupdeluxe that takes several hours. I'm afraid I couldn't find the relevant revision (But for the release I can try).

[wp]

No problem. I can try myself.

[EDIT]
The change is introduced by r56975, "IDE: new designer option: Force DPI scaling in design-time". This introduces the "Force DPI scaling in design-time" checkbox. Therefore, I guess that in order to avoid changing of scaling by the IDE when a project is moved to another computer at different dpi this checkbox should be turned off, as already has been suggested somewhere (I myself have never changed this option...)