[macOS] Consider transformation scale in GC.drawImage(image, x, y) #2919#3246
Draft
HeikoKlare wants to merge 1 commit intoeclipse-platform:masterfrom
Draft
[macOS] Consider transformation scale in GC.drawImage(image, x, y) #2919#3246HeikoKlare wants to merge 1 commit intoeclipse-platform:masterfrom
HeikoKlare wants to merge 1 commit intoeclipse-platform:masterfrom
Conversation
…lipse-platform#2919 With e97143c, support was added on Windows to take the Transform scaling into consideration when calling drawImage(image, x, y). Especially when used in combination with an SVG-based image, this leads to better results as the best-fitting image representation is used for painting, rather than relying on interpolation. This change follows the same logic for Cocoa/macOS, equivalent to what has already been done for Windows and is being done for GTK in eclipse-platform#3201. When a Transform is active on the GC, the call to drawImage(image, x, y) is delegated to drawImage(image, x, y, w, h), using the image's natural bounds as the destination size. Within that method, the destination dimensions are multiplied by the effective transformation scale before being passed to executeOnImageAtSizeBestFittingSize(), so that the higher-resolution image representation is selected and rendered at its full quality rather than being upscaled from a lower-resolution variant. The effective scale is derived from the active NSAffineTransform via Math.hypot() on the matrix columns, which correctly handles transforms that combine scaling with rotation. The existing test test_drawImageLorg_eclipse_swt_graphics_ImageIIII_withTransform, which was previously restricted to Windows only, is now enabled on all platforms (the @EnabledOnOs(OS.WINDOWS) guard and its now-unused imports are removed). The previously un-annotated companion test test_drawImageLorg_eclipse_swt_graphics_ImageIIII_withTransform_zeroTargetSize receives the missing @test annotation so it is actually executed. Contributes to eclipse-platform#2919
Contributor
Test Results 174 files - 8 174 suites - 8 26m 36s ⏱️ -42s For more details on these failures, see this check. Results for commit a084b4b. ± Comparison against base commit 57fe5a5. This pull request removes 76 and adds 2 tests. Note that renamed tests count towards both. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR ports the transformation-scale-aware image drawing logic to Cocoa/macOS, following the same approach previously applied to Windows (e97143c) and currently being introduced for GTK in #3201.
Background
When a scaled
Transformis set on aGCanddrawImage(image, x, y)is called, SWT should select the best-fitting image representation (e.g. the high-resolution variant of an SVG-backed image) for the effective on-screen size — accounting for both the destination rectangle and the active transformation scale. Without this fix, the code ignores the transformation scale and passes only the nominal destination size to the image-selection logic, which causes a lower-resolution representation to be rendered and then upscaled, producing blurry results especially noticeable with SVG images.Changes
bundles/org.eclipse.swt/Eclipse SWT/cocoa/org/eclipse/swt/graphics/GC.javacalculateTransformationScale()— extracts the effective scale factor from the activeNSAffineTransformusingMath.hypot()on the matrix columns (m11/m21andm12/m22), which yields the correct scale even when the transform combines scaling with rotation.drawImage(Image, int, int)— when a non-null transform is active, delegates todrawImage(image, x, y, w, h)using the image's natural bounds, routing through the scale-aware path instead of the legacy simple path.drawImage(Image, int, int, int, int)— multiplies the destination dimensions by the transformation scale before passing them toexecuteOnImageAtSizeBestFittingSize(), ensuring the most appropriate image representation is loaded at the effective rendered resolution.tests/org.eclipse.swt.tests/JUnit Tests/org/eclipse/swt/tests/junit/Test_org_eclipse_swt_graphics_GC.java@EnabledOnOs(OS.WINDOWS)guard (and now-unusedEnabledOnOs/OSimports) fromtest_drawImageLorg_eclipse_swt_graphics_ImageIIII_withTransform— the test now runs on all platforms.@Testannotation totest_drawImageLorg_eclipse_swt_graphics_ImageIIII_withTransform_zeroTargetSize, which was previously never executed.Both tests pass on macOS.
Relation to other PRs
Test plan
test_drawImageLorg_eclipse_swt_graphics_ImageIIII_withTransformpasses on macOStest_drawImageLorg_eclipse_swt_graphics_ImageIIII_withTransform_zeroTargetSizepasses on macOSdrawImage(image, x, y)under a scaledTransformrender at full sharpness on macOSThis change was created with the assistance of Claude Code (Anthropic).