Limit monitor-specific scaling to supported autoscale modes

[HeikoKlare]

Current Behavior
Currently, monitor-specific scaling can be combined with autoscale modes quarter, exact, false and a fixed zoom set to swt.autoScale. For any other value, applications will not start as Display instantation fails with an exception in Win32DPIUtils#setAutoScaleForMonitorSpecificScaling().
This has multiple issues:

• Applications will fail to start with an invalid configuration. In particular, when someone has set int200 explicitly in an older Eclipse (< 2025-06) and updates to a recent one (which will automatically enable monitor-specific scaling), the application will not start afterwards.
• This implicit dependency of monitor-specific scaling to specific autoscale values is not made prominent to the user. They can just enable monitor-specific scaling in the preferences and the application may fail to start afterwards because an incompatible autoscale value was specified.
• We still allow quite many kinds of autoscale mode, which all need to be tested. On the long run, it would be good to establish monitor-specific scaling as the only relevant default and support as few autoscale modes as possible (such as quarter, fixed and false, but not the more complex fixed zoom values).

Proposed Behavior
I propose to streamline this as follows:

• SWT should by default not create a Display and log an error instead when an incompatible autoscale is set while activating monitor-specific scaling
  • From the current allow-list, the fixed zoom autoscale values should be removed
  • A system property should be added that disables this compatiblity check at own risk
• Eclipse products should not enable monitor-specific scaling if an incompatible autoscale value is set
  • The preference option should be disabled and a tooltip (or maybe a message next to the preference label) should say that an incompatible autoscale value was defined via system property or ini
  • If the preference was enabled before and an incompatible autoscale value is defined, a popup should be presented to the user indicating the incompatibility (to address the migration scenario where the user had an autoscale value defined in the ini and via the update monitor-specific scaling is enabled by default).

Implementation Hints
To achieve that we can do all this in the Workbench without replicating SWT logic, we should probably start providing some public API to SWT for this, e.g.:

• An AutoScaling class with:
  • isSetupCompatibleToMonitorSpecificScaling() which returns false if not on Windows or if an incompatible autoscale value is specified
  • enableMonitorSpecificScaling() that enables the monitor-specific scaling (no matter if its compatible or not) just like DPIUtil.setMonitorSpecificScaling() does not
  • We might move DPIUtil#runWithAutoScaleValue() or a more streamlined version of that method to this class so that Workbench can use a public API method instead of currently using an internal method.

Maybe some more functionality in that class could be useful, also to improve / parameterize tests.

Instead of making that class public API, we could also put it in a package that is x-friends to the Workbench-containing bundle.

[fedejeanne]

How about an API that:

• Lets the consumer (Workbench) try to (de)activate the m.s.s.
• Throws an error (with a descriptive message) if the (de)activation couldn't be carried out because of conflicting configurations via start parameters

?

That way we would be covered for both the use cases when the user updates to a newer Eclipse version and also for when we start deprecating/removing some other invalid combination of parameters from SWT.

[HeikoKlare]

How about an API that:

• Lets the consumer (Workbench) try to (de)activate the m.s.s.
• Throws an error (with a descriptive message) if the (de)activation couldn't be carried out because of conflicting configurations via start parameters

I see the benefit of providing an error message but I am not sure if the creation of the error message is/should be the responsibility of this business logic. I could image that a log message for this case (when using an invalid SWT configuration) or a GUI message from the workbench (when falling back to other behavior) need to be different. In particular, an SWT application with an invalid configuration should simply not start whereas I see this fallback logic of deactivating monitor-specific scaling when the configuration is incompatible as a pure Eclipse Platform feature.