Avoid attempt to draw images with target width/height of 0#3079
Merged
HeikoKlare merged 1 commit intoeclipse-platform:masterfrom Feb 12, 2026
Merged
Avoid attempt to draw images with target width/height of 0#3079HeikoKlare merged 1 commit intoeclipse-platform:masterfrom
HeikoKlare merged 1 commit intoeclipse-platform:masterfrom
Conversation
Contributor
HeikoKlare
force-pushed
the
issue-3078
branch
from
81a9589 to
712ca0c
Compare
Recently, the ability to scale images for the desired target size of a drawImage operation executed on a GC and the incorporation of a Transform potentially applied to that GC have been implemented. With this, the target size for an image to be drawn can become 0 and the request of a handle of that size can fail, in particular when trying to rasterize an SVG at that size. This change adapts the implementation of the handle retrieval for a desired size in the Image implementation so that the minimum size of the provided handle is 1 in both of the dimensions. The draw operation in the GC will then take care of potentially not drawing anything at all when the actual intended size is really 0. It also adds a test case for the specific case of requesting a handle at size 0 and also adds a test for the general correctness of image handle retrieval when a transform is applied to the GC. Fixes eclipse-platform#3078
HeikoKlare
force-pushed
the
issue-3078
branch
from
712ca0c to
aaa4309
Compare
Contributor
Author
|
Consequences of the addressed issue (failing GC operations) are potentially severe, such that this issue should be fixed for the release. In order to have it tested with the last milestone build to detect potential unintended effects, this should go in M3. Unintended effects are unlikely though as the issue is about the intent to draw an image at width or hight 0, such that the actual image content is irrelevant anyway. |
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.
Recently, the ability to scale images for the desired target size of a drawImage operation executed on a GC and the incorporation of a Transform potentially applied to that GC have been implemented. With this, the target size for an image to be drawn can become 0 and the request of a handle of that size can fail, in particular when trying to rasterize an SVG at that size.
This change adapts the implementation of the handle retrieval for a desired size in the Image implementation so that the minimum size of the provided handle is 1 in both of the dimensions. The draw operation in the GC will then take care of potentially not drawing anything at all when the actual intended size is really 0.
It also adds a test case for the specific case of requesting a handle at size 0 and also adds a test for the general correctness of image handle retrieval when a transform is applied to the GC.
Fixes #3078