You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have tried finding issue with the usage of getDeviceZoom in org.eclipse.swt.dnd.ImageTransfer.nativeToJava(TransferData) using example ClipboardExample class Image transfer option. No visible issue found.
Update:
While running the ClipboardExample on a primary monitor set to 150% scaling, the following behavior was observed:
Selecting an image from the file system and pressing the Copy button copies the image data to the clipboard with the DeviceZoom value set to 150% (the scaling of the primary monitor).
Moving the application shell to a secondary monitor with 100% scaling and pressing the Paste button retrieves the image data from the clipboard and displays the image based on the original DeviceZoom (150% from the primary monitor).
This results in the pasted image appearing larger on the secondary monitor, as it is rendered with the DeviceZoom of the primary monitor instead of adapting to the scaling of the current monitor.
Steps to reproduce:
Run the ClipboardExample with following VM arguments
Open an image on primary monitor (150%) and press copy button
Move the shell to other monitor (200%) and press paste button
Observed Behavior:
The pasted image appears larger on the secondary monitor because the image data uses the DeviceZoom from the primary monitor (150%) instead of adjusting to the scaling of the current monitor (100%).
Suggested Solution:
To address this issue, the image data copied to the clipboard should not retain the zoom level from the original monitor. Instead, the application should adapt the zoom level dynamically based on the context of the monitor where the image is pasted. This ensures consistent rendering across monitors with different scaling factors.
After discussing the issue with Shahzaib my opinion is that the whole implementation doesn't make much sense in monitor-specific scaling setting. There is not real contract defined in the method, javadoc only states, that it should return ImageData. What we probably could or should do is pass a target zoom via TransferData, to define the zoom of the ImageData, that is returned to at least get rid of the getDeviceZoom call. Nevertheless the usage of the ImageTransfer is not existent, at least not in the platform.
Uh oh!
There was an error while loading. Please reload this page.
I have tried finding issue with the usage of getDeviceZoom in
org.eclipse.swt.dnd.ImageTransfer.nativeToJava(TransferData)
using exampleClipboardExample
class Image transfer option. No visible issue found.Update:
While running the ClipboardExample on a primary monitor set to 150% scaling, the following behavior was observed:
Selecting an image from the file system and pressing the Copy button copies the image data to the clipboard with the DeviceZoom value set to 150% (the scaling of the primary monitor).
Moving the application shell to a secondary monitor with 100% scaling and pressing the Paste button retrieves the image data from the clipboard and displays the image based on the original DeviceZoom (150% from the primary monitor).
This results in the pasted image appearing larger on the secondary monitor, as it is rendered with the DeviceZoom of the primary monitor instead of adapting to the scaling of the current monitor.
Steps to reproduce:
ClipboardExample
with following VM argumentsObserved Behavior:
The pasted image appears larger on the secondary monitor because the image data uses the DeviceZoom from the primary monitor (150%) instead of adjusting to the scaling of the current monitor (100%).
Suggested Solution:
To address this issue, the image data copied to the clipboard should not retain the zoom level from the original monitor. Instead, the application should adapt the zoom level dynamically based on the context of the monitor where the image is pasted. This ensures consistent rendering across monitors with different scaling factors.
Hint
The text was updated successfully, but these errors were encountered: