Community
Participate
Working Groups
To be able to contribute to SWT I have executed the Unit-Tests from AllWidgetTests. On my platform (Windows 10, Hi-DPI Display) 70 test cases fail. Looks like the reason for most (if not all) is the same. The tests expect to find Point(0, 0) but actually Point(1, 1) is returned. Here are two example failures: java.lang.AssertionError: expected:<Point {0, 0}> but was:<Point {1, 1}> at org.eclipse.swt.tests.junit.Test_org_eclipse_swt_widgets_Control.test_toControlII(Test_org_eclipse_swt_widgets_Control.java:744) java.lang.AssertionError: expected:<Point {0, 0}> but was:<Point {1, 1}> at org.eclipse.swt.tests.junit.Test_org_eclipse_swt_widgets_Control.test_toControlLorg_eclipse_swt_graphics_Point(Test_org_eclipse_swt_widgets_Control.java:749) I'm not sure if this is indicating a bug or is a flaw in the tests.
Investigating.
Hello Arne, I just ran tests locally on my windows 10 (64 bit) test machine as of newest commit. (12:42 today). AllTests pass. The only thing that comes to mind is the hi-dpi business. Does the issue occur if your dpi is set to low/regular? (There is work in progress to support hidpi).
I can confirm that this is related to Hi-DPI. If I set scaling to 100%, lower the resolution and restart windows all tests are green. After switching back to 250% scaling and 3840x2160 the tests fail again. I can observe that the failings are not stable. Sometimes 70 cases fail, somtimes 62 or 69 ... I have exectued "Test_org_eclipse_swt_widgets_Control.test_toControlII" a lot. For 20 executions is has succeeded only once.
Maybe it is also important to know that I use the Oxygen release with checked out SWT projects, not an I-build or something. There are native libraries that might be out of date, right? Do I need to install an I-build or is the release version ok?
(In reply to Arne Deutsch from comment #3) > I can confirm that this is related to Hi-DPI. If I set scaling to 100%, > lower the resolution and restart windows all tests are green. After > switching back to 250% scaling and 3840x2160 the tests fail again. Yes, these test failures at HiDPI are a result of rounding errors, which happens in the process of converting Points to Pixels(which is native equivalent value as per the monitor resolution) and visa versa.
Root cause: SWT coordinate system is in 'integer', and after up or down-scaling Point values result in 'float' which cannot be passed as is to native layer which accepts 'integer' values and scaled 'float' values are rounded to nearest 'integer' and leading to loss of precision in complex bound calculations.
(In reply to Arne Deutsch from comment #4) > Maybe it is also important to know that I use the Oxygen release with > checked out SWT projects, not an I-build or something. There are native > libraries that might be out of date, right? Do I need to install an I-build > or is the release version ok? There should be no problem in using the Oxygen release build. The tests by default run against the checked-out SWT projects in the workspace. Your setup should be fine, if you have the same branch (master) checked out in both source and binaries repositories and they are up to-date.
Would such miscalculations probably lead to visible artifacts? If the position of a widget is of by one a thin black line or similar might appear!? And even worse, the line might appear depending if the widget is positioned ot an odd or even line ... for me it looks like this is not tolerable. Just an idea: If the calculations are not done a MASSIVE amount of times, probably it is possible to not simply pass a "Point" with x/y to the native layer but something like a "ScaledPoint" with x/y/unscaledX/unscaledY?. The calculations could then be done always on "unscaled" values and scaled values are derived from that. Successive Down/Up-Scaling would then not lead to loss of precision. Independently of the actual solution it looks to me as if a loss in precisionneeds to be avoided by enriching the concept of a Point witg some scaling information.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
