Replacing the usage of getBoundsInPixels with getBounds #1385
Conversation
ShahzaibIbrahim
force-pushed
the
master-105
branch
from
fd87956 to
72e8cb6
Compare
| @@ -7293,7 +7293,7 @@ LRESULT wmNotifyToolTip (NMTTCUSTOMDRAW nmcd, long lParam) { | |||
| if (pinfo.iSubItem != 0) x -= gridWidth; | |||
| Image image = item.getImage (pinfo.iSubItem); | |||
| if (image != null) { | |||
| Rectangle rect = image.getBoundsInPixels (); | |||
| Rectangle rect = image.getBoundsInPixels(); | |||
There was a problem hiding this comment.
Is it intended that this is only a formatting change?
There was a problem hiding this comment.
formatting leftover
| @@ -466,7 +466,7 @@ void copyAreaInPixels(Image image, int x, int y) { | |||
| if (image == null) SWT.error(SWT.ERROR_NULL_ARGUMENT); | |||
| if (image.type != SWT.BITMAP || image.isDisposed()) SWT.error(SWT.ERROR_INVALID_ARGUMENT); | |||
| /* Copy the bitmap area */ | |||
| Rectangle rect = image.getBoundsInPixels(); | |||
| Rectangle rect = image.getBounds(data.nativeZoom); | |||
There was a problem hiding this comment.
This modifies the behavior, doesn't it?
Let's assume getBoundsInPixels() returned (100, 100, 100, 100) and let's assume that data.nativeZoom=125. Then getBounds(data.nativeZoom) will scale up from 100 to 125, i.e., it will return (125, 125, 125, 125). Do I miss something?
There was a problem hiding this comment.
Depends what the native zoom of the image is. If the native zoom of the image is 125, then it will return (100, 100, 100, 100). If the native zoom of the image is 100, then yes. Probably would be good to look out for a snippet, where this is used and play around with that.
There was a problem hiding this comment.
I do not understand that. Why should it return (100, 100, 100, 100) when the native zoom of the image is 125? Within getBounds(int), the "corrected" zoom is used according to DPIUtil.getZoomForAutoscaleProperty(initialNativeZoom), so even if the native zoom of the image is 125, a value of 100 is used for scaling, isn't it?
There was a problem hiding this comment.
So you mean the call should be getBounds(getZoom()) to be in the same zoom restrictions as Image uses internally?
That is definetly correct
There was a problem hiding this comment.
What I meant for example is the scenario was with mode exact or quarter, where the Image was e.g. created on the primary monitor with 125%. Then getBounds(125) would be equal to getZoom() from the image, so it would return (100, 100, 100, 100)
There was a problem hiding this comment.
That's true. I had the "default" case in mind (i.e., scaling mode integer200) in which I still think that the behavior might change.
There was a problem hiding this comment.
That's true. I had the "default" case in mind (i.e., scaling mode
integer200) in which I still think that the behavior might change.
You are right, the behavior changes. I tested it with the snippet 215, where image.getBoundsInPixels() returns Rectangle {0, 0, 5120, 1440} but later scaled due to native zoom (which is 200) to final value image.getBounds(data.nativeZoom) : Rectangle {0, 0, 10240, 2880}
ShahzaibIbrahim
force-pushed
the
master-105
branch
from
72e8cb6 to
0fe94e9
Compare
initial native image must be the one that will be used by a widget, thats why using getBounds with initialNativeZoom
ShahzaibIbrahim
force-pushed
the
master-105
branch
from
0fe94e9 to
2bc5089
Compare
Initial native image must be the one that will be used by a widget, thats why using getBounds with initialNativeZoom. This PR just remove the usage of deprecated method getBoundsInPixels wherever possible. This doesn't fix anything broken.