[Win32] Avoid duplicate application of gray/disabled image adaptation#1
Closed
HeikoKlare wants to merge 6 commits intomasterfrom
Closed
[Win32] Avoid duplicate application of gray/disabled image adaptation#1HeikoKlare wants to merge 6 commits intomasterfrom
HeikoKlare wants to merge 6 commits intomasterfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR refactors the application of gray/disabled image adaptations in the Win32 Image implementation to eliminate duplicate processing and improve consistency. Previously, both the loadImageData() methods and their callers were applying these adaptations, resulting in unnecessary duplicate transformations.
Changes:
- Centralized gray/disabled adaptation responsibility to
loadImageData()andloadImageDataAtExactSize()provider methods - Removed redundant adaptation calls from consumers of these methods
- Added documentation clarifying that provider methods return pre-adapted image data
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
When requesting an ImageList from a Display, the zoom is currently not considered when scanning through the existing image lists for a matching one. This can lead to an image list with a wrong zoom being used, such that the contained image handles are not properly fitting in size and thus need to be scaled. This changes includes the zoom into the identification of whether one of a Display's image lists fits to the requested properties or not. To this end, the whole validation logic is moved to the ImageList class itself, such that it's style and zoom do not need to be exposed unnecessarily.
…atform#2119 Control: don't send MouseMove events with stateMask set for BUTTON1 before the MouseDown event was sent These events are already added to the dragDetectionQueue, so there is no need to send/post them now.
The Tray implementation uses the default constructor of the Widget class. When using that constructor, the nativeZoom of the widget is not initialized. In case of a Tray, contained TrayItems inherit that zoom and will fail to get an image set because the zoom is zero. With this change, a TrayItem will initialize its native zoom based on the zoom of the context device.
When an image is created with SWT.IMAGE_GRAY or SWT.IMAGE_DISABLE, an adaptation of the loaded/created image data is performed to make it look grayed/disabled. The according functionality is currently applied by callers of loadImageData() right afterwards. Since for every consumption of an image data/handle the loadImageData() method needs to be called, this ensures that the image data is always adapted correctly. In the implementation for an ImageGcDrawer, the adaptation for gray/disabled is currently executed within the loadImageData() method. The same applies to implementation for an existing handle and a plain image, as they will simply scale existing image data (which already have the gray/disabled adaptation applied). Since consumers of that method perform the adaptation as well, this leads to an unnecessary duplicate application of the adaptation and to inconsistent behavior throughout the implementations of loadImageData(). This change streamlines the implementation in the Image class by properly assigning the responsibility for applying gray/disabled adaptations as follows: - the copy constructor accepting the gray/disabled flag applies the style to copied handles, just like it does now - on retrieval of new image data or handles for zoom/sizes, the loadImageData() and loadImageDataAtExactSize() method of the provider classes are responsible for delivering data with the styling being applied This relieves all consumers of those methods from taking care of applying the style and properly assign it to those two methods and the implementation.
HeikoKlare
force-pushed
the
streamline-adaptgraydisabled-inloadimagedata
branch
from
40d0ca8 to
1bafbae
Compare
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
2 participants
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.
When an image is created with SWT.IMAGE_GRAY or SWT.IMAGE_DISABLE, an adaptation of the loaded/created image data is performed to make it look grayed/disabled. The according functionality is currently applied by callers of loadImageData() right afterwards. Since for every consumption of an image data/handle the loadImageData() method needs to be called, this ensures that the image data is always adapted correctly.
In the implementation for an ImageGcDrawer, the adaptation for gray/disabled is currently executed within the loadImageData() method. The same applies to implementation for an existing handle and a plain image, as they will simply scale existing image data (which already have the gray/disabled adaptation applied).
Since consumers of that method perform the adaptation as well, this leads to an unnecessary duplicate application of the adaptation and to inconsistent behavior throughout the implementations of loadImageData().
This change streamlines the implementation in the Image class by properly assigning the responsibility for applying gray/disabled adaptations as follows:
This relieves all consumers of those methods from taking care of applying the style and properly assign it to those two methods and the implementation.