WinEdt and dpi-awareness
Windows applications may be deployed on monitors with very different resolutions (form basic 96dpi to UHD 192dpi or more) and this presents developers with serious challenges. If you are new to the concept of dpi-awareness you can consult MS guidelines (if you find them complicated it is because they are indeed non-trivial):
WinEdt is system dpi-aware: it comes with high-quality graphic resources at different sizes and at startup it automatically adjusts its GUI to high-resolution displays (without stretched or blurred graphics and text). For most users this is the desired behavior.
However, Windows (even version 10) currently does not properly scale Minimize, Restore, and Close buttons that are paced to the right side of the menu for maximized MDI child Windows. This can make these buttons (much) too small on high resolution displays. Some users report this as a bug in WinEdt. Not so: it is a known Windows MDI problem and a fix is up to MS. Furthermore, MDI child window frame appearance (when not maximized) does not match the theme on Windows 8 or 10. This, too, is a known Windows problem with all MDI applications and it will have to be addressed by Microsoft...
Windows 8 introduced per monitor dpi-awareness. In principle this makes it possible for applications to adjust to the resolution of the monitor on which they are paced rather than the system resolution of the primary monitor which may be different when multiple or external monitors are used. Alas, this functionality does not work properly for (desktop) MDI applications as it is currently impossible to properly scale menus and frames for child Windows. With some custom code top-level Windows can be properly scaled as of Windows 10 anniversary update (Sep, 2016) or later. At this moment popup menus are not properly scaled and neither are disabled menu images. Until these problems are addressed by MS WinEdt will not be dpi-aware per monitor as it would not behave properly!
This being explained WinEdt will be subject to DPI Virtualization and scaling if placed on a secondary monitor with a different resolution than the primary one (Windows system dpi setting/ magnification). It this case it may appear blurry. There may also be other refresh problems and oddities in this case as both Windows and Delphi still have to iron out many problems with such scenarios. Thus it is best to run WinEdt on a primary monitor or a monitor with the same resolution as the primary one.
Because of the problems described above some (but not many) users may prefer non dpi-aware version of WinEdt. Upon request I will make such versions available for new releases of WinEdt (it is just a matter of changing dpi-awareness attribute in WinEdt's manifest file). Let me know if (and why) you would prefer non dpi-aware version...
Note: WinEdt versions prior to 9 are not dpi-aware!