Implementation of GC to enable multi zoom level support for win32
Issues: https://github.com/eclipse-platform/eclipse.platform.swt/issues/62 and https://github.com/eclipse-platform/eclipse.platform.swt/issues/131
This pull request is a base pull request for several following PRs which implement multi zoom level support for different components (resources, widgets, etc).
In this PR, the focus is on GC to enable it to use the zoom level information which is added to widget. Also, it provides zoom level information in GCData which can later be used by resources like Image, Region, etc which don't have the zoom information since they are not a widget. Also, GC now uses the DPIUtil methods with zoom for getting the size as per the zoom level. This zoom in GC is derived from the GCData where we add the zoom information.
Note: Only the last commit is the relevant commit because it is based on the PR https://github.com/eclipse-platform/eclipse.platform.swt/pull/1229. Must be merged after https://github.com/eclipse-platform/eclipse.platform.swt/pull/1229 has been merged.
Test Results
418 files ±0 418 suites ±0 9m 15s :stopwatch: +27s 4 121 tests ±0 4 113 :white_check_mark: ±0 8 :zzz: ±0 0 :x: ±0 16 313 runs ±0 16 221 :white_check_mark: ±0 92 :zzz: ±0 0 :x: ±0
Results for commit f23c7211. ± Comparison against base commit 567a8b40.
:recycle: This comment has been updated with latest results.
I just wanted to note that (platform dependent) package private or even public fields / methods are quite common, they should just be documented in this case as platform dependent.
I just wanted to note that (platform dependent) package private or even public fields / methods are quite common, they should just be documented in this case as platform dependent.
@laeubi Is it really necessary to specify that a package private field/method inside a fragment is platform-dependent? I mean the fragment is already platform-dependent and the field/method can't be seen outside the fragment. Or am I missing something?
@fedejeanne I have only seen it on public field, so maybe in my sentence it should read as an XOR so:
Either the field is package private or instead public but clearly documented to be platform dependent.
:-)
The tests are broken
Note that new test classes in a test plug-in usually need to be added to the plug-ins test suite. In the win32 SWT tests, this is the AllWin32Tests test suite. If you do so for the new GCWin32Tests, the PR build will fail on Windows because of the test failures mentioned by @fedejeanne.
If you cannot provide reasonable, sufficient tests via public API only, you need to add the test cases in the win32 fragments, as prepared for the DefaultSWTFontRegistry and ScalingSWTFontRegistry in #1203.
It seems that some fields added here will not be necessary in future PRs (see
ShellandWidget), please remove them.Also, the method
GCData::setNativeZoomForGCDatasuffers from a code smell, it would be nice if it's not necessary or if it can be done differently.Have the tests been addressed yet?
I updated this PR with respect to the PR #1229. It should look more consistent now.
@amartya4256 merging the required PR introduced a conflict in this PR, so please resolve and rebase on master once you find the time
@amartya4256 merging the required PR introduced a conflict in this PR, so please resolve and rebase on master once you find the time
This PR now depends on https://github.com/eclipse-platform/eclipse.platform.swt/pull/1258 because of splitting the OS bindings to a separate PR. I have rebased it to the PR and I would update the description.