Use Float Aware Geometry for Scaling #62

[amartya4256]

This PR introduces FloatAwareRectangle and FloatAwarePoint as an extension of Rectangle and Point respectively to improve scaling precision in the DPIUtil by using residuals obtained from rounding.

Contributes to
#62 and #128

[github-actions]

Test Results

104 files   -    441  104 suites   - 441   8s ⏱️ - 32m 36s
 66 tests  -  4 333   65 ✅  -  4 316  0 💤  -  18  1 ❌ +1 
213 runs   - 16 510  212 ✅  - 16 370  0 💤  - 141  1 ❌ +1 

For more details on these failures, see this check.

Results for commit ff5192d. ± Comparison against base commit e40ad29.

This pull request removes 4333 tests.

AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicASCII_dollarSign
AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicASCII_emptyString
AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicASCII_letterA
AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicASCII_letters
AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicUTF16LE_null
AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicUTF16_AsciiLetters
AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicUTF16_Asciiletter
AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicUTF16_LotsOfLetters
AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicUTF16_letter
AllGTKTests org.eclipse.swt.tests.gtk.Test_GtkConverter ‑ test_HeuristicUTF16_letters
…

[laeubi]

I must confess that this XyzAware things sound strange from an object oriented point of view. one would always question e.g. if the fields are synchronized with the integer variants.

Is there any reason to not have proper getter/setter instead of public modifiable fields? The e.g. a setX(double) can always update the integer fields as well.

Also one might look at how AWT is doing it here: https://docs.oracle.com/javase/8/docs/api/java/awt/geom/Rectangle2D.html

So the have

• https://docs.oracle.com/javase/8/docs/api/java/awt/Rectangle.html (integer coordinates)
• https://docs.oracle.com/javase/8/docs/api/java/awt/geom/Rectangle2D.Float.html (float coordinates)
• https://docs.oracle.com/javase/8/docs/api/java/awt/geom/Rectangle2D.Double.html (double coordinates)

[HeikoKlare]

I must confess that this XyzAware things sound strange from an object oriented point of view. one would always question e.g. if the fields are synchronized with the integer variants.

Is there any reason to not have proper getter/setter instead of public modifiable fields? The e.g. a setX(double) can always update the integer fields as well.

Also one might look at how AWT is doing it here: https://docs.oracle.com/javase/8/docs/api/java/awt/geom/Rectangle2D.html

I don't see a good reason to not have proper getter/setters for the newly added fields. One issue from OO perspective is that we have the public fields in the existing Rectangle/Points classes which are accessed directly everywhere and makes it difficult to properly extend the classes. But for the additional classes with higher precision, which are only supposed to be used inside SWT at least for now anyway, it definitely makes sense to apply proper encapsulation.

I also agree that that names sound strange, at least the float version (for MonitorAware* it makes more sense to me).
Thank you for the reference to the AWT classes. I was not aware of them. Having the specializations realized as inner classes, so that you can have a Rectangle.Float (and maybe then also a Rectangle.WithMonitor or the like) sounds like a reasonable approach that we could also apply here.

[arunjose696]

shouldnt the tests be testing FloatAwareRectangle too?

[amartya4256]

DPIUtil is responsible for creating the FloatAwareRectangle from Rectangle internally. Hence, this test is already testing FloatAwareRectangle internally.

[laeubi]

But for the additional classes with higher precision, which are only supposed to be used inside SWT at least for now anyway,

I'm not sure if we should design such "supposed to be internal" API here. Actually one big drawback of SWT compared to eg. Graphics2D is its inability to use floating point arithmetic in most places. One can prevent this by constructing a Path (that supports at least float), so I see an opportunity enable such advanced use cases with using "Double/Float" variants of rectangle, point and so on ... especially if transforms / scaling comes into play now it seems to limited to only allow integer / pixel drawing.

[HeikoKlare]

I'm not sure if we should design such "supposed to be internal" API here.

I think this is a misunderstanding. I did not want to propose to design an API that is supposed to only be internal. I just wanted to say that these classes are only supposed to be used internally for now, so still having the chance for redesign before they are eventually made public API. We should first adapt the code inside SWT to properly handle higher-precision coordinates (for the reasons you also mentioned) and see where/whether we run into problems there and what needs to be done to adapt all consumers of Point/Rectangle to properly handle the higher-precision versions of them. Afterwards, once we know how to properly do it and once everything is implemented, we can make it API public. If we would do it now, strange things would happen as a consumer could pass a point with floating-point precision to consumers inside SWT without them being adapted to properly consider the higher-precision value. So there is quite some need to adaptation before we might do that.