-
Notifications
You must be signed in to change notification settings - Fork 182
Use OS.CreateIconIndirect for colored cursors with source and mask #2517
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
491e76f
to
de5bba9
Compare
Test Results 118 files ±0 118 suites ±0 10m 54s ⏱️ +48s For more details on these failures, see this check. Results for commit f271319. ± Comparison against base commit 35119f0. ♻️ This comment has been updated with latest results. |
bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/graphics/Cursor.java
Outdated
Show resolved
Hide resolved
de5bba9
to
7b36487
Compare
Previously, the Cursor constructor that accepted both source and mask used OS.CreateCursor, which only supports monochrome cursors. As a result, any color information in the source was ignored and the cursor always appeared black. This change updates the constructor to use OS.CreateIconIndirect, allowing full-color cursors while still respecting the mask for transparency. DPI scaling of the source and mask now works correctly with colored cursors. # Conflicts: # bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/graphics/Cursor.java
7b36487
to
f271319
Compare
Failing test are unrelated, see #2516 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some concerns about this change:
- It introduces unnecessary complexity to
setupCursorFromIamgeData
as that internal utility method is made capable of handling cases that can not occur (or at least that were also not supported) by the existing API. - It change the return type of
getPointerSizeScaleFactor()
without any obvious need, increasing the complexity of consumer code. - The code is not properly formatted.
ImageData scaledMask = this.mask != null ? DPIUtil.scaleImageData(device, mask, zoom, DEFAULT_ZOOM) | ||
: null; | ||
return setupCursorFromImageData(scaledSource, scaledMask, getHotpotXInPixels(zoom), getHotpotYInPixels(zoom)); | ||
float zoomFactor = getPointerSizeScaleFactor() * ((float) zoom) / 100f; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why change the return type of getPointerSizeScaleFactor()
to float and have all these integer conversions / roundings in this method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #2517 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pointer. But then it's an issue unrelated to this PR but an issue with the existing implementation, isn't it? So please extract an appropriate PR for a separate issue out of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could simply fix it here. The method was introduced 2 weeks ago in 6e4241d. That's probably why nobody noticed so far.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is unrelated to this PR, so please have separate PRs for unrelated concerns.
long[] maskResult = Image.initIcon(device, maskData, maskData); | ||
hMask = maskResult[1]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I am not mistaken, this will apply the mask data as a mask to itself, then extract the mask data out of the combined image to finally just execute OS.CreateBitmap(i.width, i.height, 1, 1, maskData)
. Why not directly do that without all the unnecessary complexity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And if you pass mask data, why should the source data also contain alpha information? This was not supported by the existing API, so I don't think we should implement it here. It should be valid to assume that if a mask is passed the source does not contain mask data. I think we should even deprecate the source+mask constructor and indicate that better other constructors taking transparency-aware data or even an ImageDataProvider
should be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My comment was addressed 👍
See Heiko's comments
Use OS.CreateIconIndirect for colored cursors with source and mask
Previously, the Cursor constructor that accepted both source and mask used OS.CreateCursor, which only supports monochrome cursors. As a result, any color information in the source was ignored and the cursor always appeared black.
This change updates the constructor to use OS.CreateIconIndirect, allowing full-color cursors while still respecting the mask for transparency. DPI scaling of the source and mask now works correctly with colored cursors.
How to Test
Run the following snippet:
Snippet386
Cursor(Device, ImageData, ImageData, int, int)
value from drop downResult
Before:

After:

Requires