It looks like it's usual for Windows to maximize slightly outside the visible area (presumably for the invisible resize border? - Update: found this article about it ), and it must apply some offset for the client area and visual clipping. Speculation: I have a feeling that DPI scaling used by the system menu applies to other metrics, such as the window border size (for resizing), and this difference in scaling probably accounts for the window overflowing by a small amount. Another hint: in the overflowed part (on the other monitor) clicks are passed through as if it wasn't there, so this area seems clipped for click handling. The same applies the other way around: moving a working low-DPI window to the high-DPI display shows a small system menu. As if the DPI scaling has not quite fully changed when the window moved between the monitors. Observations: At step 3, right-clicking on the title bar will display a standard-sized system menu on the high-DPI display after step 4, right-clicking on the title bar will display a larger-than normal sized system menu on the low-DPI display. Maximize VS Code and observe that the window now extends slightly beyond the desktop area in all directions.Connect standard DPI display and move VS code window to the display.Ensure standard DPI display is disconnected, leaving only high-DPI display.I have this issue, and I think I have a reliable way to reproduce it, a possible explanation, and a workaround.īackground: I have one high-DPI display on a laptop, and a standard DPI monitor.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |