Plans for using floats (doubles) in GC methods?

[FluBBaOfWard]

Is your feature request related to a problem? Please describe.
Now that SWT has better support for HiDPI and scaling, the drawing methods in GC seem a bit limited, running with 200% scaling means we can only address every other pixel when drawing (unless you change the scaling and input values yourself before).

Describe the solution you'd like
If possible change the input arguments to floats/doubles, if that is not possible add new methods which takes floats/doubles (and use these arguments to the backend).

Describe alternatives you've considered
I tried to change the scaling manually and scale the input values, this works in most cases but the font handling breaks.

Additional context
On MacOS the backend is using doubles already but I have not looked into other platforms yet.

[HeikoKlare]

This is a known limitation, and I am not aware of any existing efforts for adding GC methods that accept float/double values. There have been discussions about such an extension, but the precise demand (concrete use cases) are not sufficiently clear (see details below). Changing the existing methods will not be possible because it would break the API.

Note that it would not be that easy to implement an according float/double-based API, as there is quite some specific behavior with the existing int-based APIs. As just one example, depending on the defined line height, 0.5 is added to or removed from the values of a line position, for which you have to decide if you want to have this behavior consistent with the float/double-based API or whether you want to have more "straightforward" behavior there.

That said, we need to keep in mind that SWT's autoscaling mechanism and most the according APIs are supposed to abstract from the fact that logical (point) and phyical (pixel) coordinates differ. For pure 100% rendering, the integer-based coordinates are usually fine, so from the point of view of an API consumer, having to deal with float-based values exposes the internal handling of autoscaling to a certain degree (which is by the way specific to Windows as macOS and Linux do that differently).
This autoscaling works quite well for UI components where it's not so much about being pixel-perfect but about a consistent result of the overall UI. So the question is if you already see limitations in this use case.

Regarding pixel-perfect rendering: this does not work well with the idea of autoscaling at all. For pixel-perfect rendering scenarios, there is already the possibility to disable auto-scaling for the control in which you want to render, see https://eclipse.dev/eclipse/markdown/?f=news/4.39/platform_isv.md#api-to-disable-autoscaling-for-controls
This is, in my opinion, the better approach than using float-based values to work around the UI autoscaling for pixel-perfect rendering.

So in case one really wants to invest the effort into providing a float/double-based GC API (which would be quite some work to do it properly), I propose to first analyze the actual limitations of the existing API and find out if and where autoscaling for controls and disabled autoscaling for pixel-perfect rendering is insufficient and if that cannot be solved differently. There are some fundamental flaws in how the GC operations behave, so improving that or providing better alternatives for that may also be a solution.

[FluBBaOfWard]

Our use case is a graph where we handle translation & scaling "manually", since it makes mouse interaction easier, but then the layout is not aligned/jumps around. I'm not really adamant about having every pixel addressable but it feels a bit archaic to use integers when drawing UIs in this day and age.

Changing the existing methods will not be possible because it would break the API.

Are you talking about the ABI, or is this considered the same thing in Java? I'm still not an expert in these lower level things in Java, but to me it looks like you can call a method that takes double arguments but you supply an integer instead without warnings. But I think new methods is probably better as a start anyway.

Note that it would not be that easy to implement an according float/double-based API

My proposal would be to handle floats/doubles the exact same way as ints today, just document the methods correctly in what they do if necessary. I don't remember how MacOS (Quartz?) does but I think they did add half a point for all coordinates so that integers are handled the way people expect them to. Is the big issue to add new methods to SWT or am I under estimating the workload to code this?

[HeikoKlare]

My proposal would be to handle floats/doubles the exact same way as ints today, just document the methods correctly in what they do if necessary.

Since the current methods already have an unexpected behavior when it comes to autoscaling (no matter if the values are passed as integers or with higher precision), this will not provide any benefit.
As mentioned before, for your use case you should probably have a look at disablement of autoscaling for specific controls, which will give you the full control for pixel-perfect rendering. I am still confident that the issue not so much rooted in not providing API that accepts floats/doubles but rather in the general limitations of autoscaling and the flaws we have in the current implementation of the methods with that.

[tmssngr]

Is the complete disabling of autoscaling (but keep the font scaling; System.getProperties().putIfAbsent("swt.autoScale", "false");) still officially supported?

[HeikoKlare]

The option is still available and processed, but there are no tests for it and it is not actively maintaned, thus it may easily break upon changes. I plan to deprecate the option soon and log according warnings, so that people are better aware of potential issues with that option.

Using the autoscaling disablement at control level will be the safer and more future-proof choice.

[tmssngr]

Thanks for answering. I strongly would vote against deprecating this option because it currently is the only way to get a clear, exact and pixel-precise result on Windows. You may consider to deprecate it again if all those rounding error glitches have been solved.

[HeikoKlare]

As said, pixel-precise rendering is possible with autoscaling disablement at control level (where it makes much more sense than scaling the whole UI on your own).
I honestly don't see any benefit in not making people aware by deprecation that an option they may use is unmaintained and can easily break in future releases. I don't say we will remove it immediate (or at all), but its quality may degrade and consumers should know about that.