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.
Follows https://github.com/eclipse-platform/eclipse.platform.swt/pull/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.