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
When a shell is partially placed at multiple monitors with different zoom levels, the layout of the drag and drop is flaky in terms of its bounds. For example, if the monitors have 100% and 200% zoom level respectivel and the shell is placed in such a way that most of its area is on 100% monitor but the DPI_CHANGED event hasn't been sent from Windows (so, the zoom level of the shell is still 200%); if we drag a CTabFolder on top of it, the drag and drog region bounds are drawn in context to 100% zoom monitor, even though the shell is still at 200%. This is because the mapping uses OS.MonitorFromWindow to find which monitor the shell is on, which is inconsistent with the state of the shell since the DPI_CHANGED event hasnt been sent from Windows to inform the shell to rescale to 100%.
Possible solution: Bind the shell with the monitor it is at by providing a private field and package protected getter to obtain the monitor, i.e. where the shell is created & when update the monitor when a DPI_CHANGED event occurs. This way, we always use the monitor associated with the shell for mapping and it also means less OS.MonitorFromWindow calls since at the moment it is called millions of time on the drag event.
The text was updated successfully, but these errors were encountered:
Follows eclipse-platform/eclipse.platform.swt#1349
When a shell is partially placed at multiple monitors with different zoom levels, the layout of the drag and drop is flaky in terms of its bounds. For example, if the monitors have 100% and 200% zoom level respectivel and the shell is placed in such a way that most of its area is on 100% monitor but the DPI_CHANGED event hasn't been sent from Windows (so, the zoom level of the shell is still 200%); if we drag a CTabFolder on top of it, the drag and drog region bounds are drawn in context to 100% zoom monitor, even though the shell is still at 200%. This is because the mapping uses OS.MonitorFromWindow to find which monitor the shell is on, which is inconsistent with the state of the shell since the DPI_CHANGED event hasnt been sent from Windows to inform the shell to rescale to 100%.
Possible solution: Bind the shell with the monitor it is at by providing a private field and package protected getter to obtain the monitor, i.e. where the shell is created & when update the monitor when a DPI_CHANGED event occurs. This way, we always use the monitor associated with the shell for mapping and it also means less OS.MonitorFromWindow calls since at the moment it is called millions of time on the drag event.
The text was updated successfully, but these errors were encountered: