ViewportPaneSWT should be DPI aware

[akater320]

On Windows 10 the viewport is rendered at the native resolution of the display. On high DPI displays frame-rates can decay quickly with the size of the viewport.
e.g. on a laptop with a 1440p display and an i7-7500U the geometry creation tools can be very laggy. I suspect things will be much worse on a 4K laptop. Maybe someone has tried?

[nprigour]

can you be a bit more specific on that one? I did not understand exactly the issue. Can you provide more specific information on the nature of the problem and how to verify it?

[akater320]

This would be more of an improvement than a bug.
My main concern is that a user will start udig on their fancy new ultrabook with a high-dpi screen then be frustrated by low frame rates. The most obvious slowdowns are with tools that draw on the blackboard layer. e.g. the zoom tool and the polygon creation tools.

After a little more testing, this doesn't seem to affect MacOS. On high-dpi displays, MacOS seems to default to system wide downsampling. uDig/SWT uses this reduced resolution when creating the rendering buffers. As a result, performance is good and rendered items, e.g. vertices and edges appear to be about the right physical size.

On Windows 10, uDig/SWT doesn't seem to respect the OS-level layout scaling. Buffers are created relative to the display's native resolution. On a 4K display, with the application window maximized, the back buffer can easily contain 6 million pixels. At 4 bytes per pixel, each frame puts a lot of pressure on Java2D and the memory bus. In addition, vertices and edges can appear very small/thin.

Assuming we can query the display's pixel density, it would be nice to have an option to target a certain resolution. For example, on high DPI displays, we might choose to render at 1/2 of the native resolution.

I wanted to get some inputs on whether this is actually an issue before I started working on it.
-Cheers