[Refactoring] Streamline calls to Image#adaptImageDataIfDisabledOrGray()

[ShahzaibIbrahim]

Enabling a consistent pattern to apply disablement or graying of an Image. They are applied whenever a handle is being created from init method. Ensuring streamline usage and avoid double calls to this method.

---

How to test

• Run the Snippet382 with following VM Argument: swt.autoScale.updateOnRuntime=true
• Move the shell between different zoom levels (100,125,150,175,200,250)
• The snippet tests different kind of image providers to create an Image.
• Expected result would be that we don't lose disabled or grayed image attributes.

---

This adaption is made on the basis of this comment: #2737 (comment)

Instead of calling the adaptImageDataIfDisabledOrGray method from init method (which could be executed even when temporary handle is created) we will now call it only when data is loaded for the first time. So instead of calling loadImageData, all providers must call loadImageDataWithGrayOrDisablement and also provide loadImageData implementation of its own. In this way we can achieve one common place to call adaptImageDataIfDisabledOrGray from.

[ShahzaibIbrahim]

I still have to keep it because a new image is created here with plainImageDataProvider which loads the data directly from handle. I am open to suggestions here.

[ShahzaibIbrahim]

@akoch-yatta @HeikoKlare Please review the PR and comments, It might not be in final shape but here I could use some suggestions.

[github-actions]

Test Results

  111 files  ±0    111 suites  ±0   17m 48s ⏱️ +7s
4 597 tests ±0  4 582 ✅ +1  14 💤  - 1  1 ❌ ±0 
  282 runs  ±0    281 ✅ ±0   1 💤 ±0  0 ❌ ±0 

For more details on these failures, see this check.

Results for commit eb0405c. ± Comparison against base commit 63d5582.

♻️ This comment has been updated with latest results.

[ShahzaibIbrahim]

@akoch-yatta can you please have a look/review if you got time?

[HeikoKlare]

Can you please explain the underlying pattern where the application of gray/disablement is supposed to be done now? The PR description states:

In this way we can achieve one common place to call adaptImageDataIfDisabledOrGray from.

But I see calls of that method from at least:

• initializeHandleFromSource
• newImageData
• getOrCreateImageHandleAtClosestSize

To assess if this is a good concept/systematics where to apply gray/disablement, it would be helpful to have a description of that concept.

In addition to that, the PR seems to contain unnecessary changes (e.g., addition of unused parameters, duplicate application of adaptImageDataIfDisabledOrGray) and also seems to remove crucial code (handle initialization in copy constructor).

[github-actions]

Test Results (win32)

   27 files   -  7     27 suites   - 7   4m 45s ⏱️ +4s
4 571 tests  - 57  4 500 ✅  - 55  70 💤  - 3  1 ❌ +1 
  110 runs   - 57    110 ✅  - 54   0 💤  - 3  0 ❌ ±0 

For more details on these failures, see this check.

Results for commit ee581d6. ± Comparison against base commit 47e2587.

This pull request removes 57 tests.

AllWin32Tests ImageWin32Tests ‑ testDisposeDrawnImageBeforeRequestingTargetForOtherZoom
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ testImageDataForDifferentFractionalZoomsShouldBeDifferent
AllWin32Tests ImageWin32Tests ‑ testImageShouldHaveDimesionAsPerZoomLevel
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromCopiedImage
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromImageForImageDataFromImage
AllWin32Tests TestTreeColumn ‑ test_ColumnOrder
…

♻️ This comment has been updated with latest results.