Hi,
Welcome to PixInsight Forum. We are aware of this problem with high-dpi screens on Mac OS X (retina displays) and Windows. On Mac OS X, the operating system automatically rescales applications that are not yet compatible with high-dpi modes. This is very nice (and OS X does a very good job) because it is a simple and transparent system to allow developers to make a smooth transition. Unfortunately, this is not the case with Windows.
This is in our to-do list, and I hope we'll have a high-dpi version of PixInsight soon, probably on Q4 2014, or perhaps Q1 2015. Don't take this as a commitment, though. The amount of work necessary is considerable, especially in a modular application like PixInsight. Note that the problem is not only with tool bar icons, but with modules and scripts, and the way they interact with the PixInsight platform. We have to change significant portions of our development frameworks in order to adapt all interfaces in a completely automatic and transparent way. While images will be displayed at native resolution, all icons, buttons and interface elements will have to adapt to different screen resolutions in a way completely transparent to modules and scripts.
Even if you have no programming knowledge, let me put a very simple example to give you a better idea of the problem. Consider the following lines of JavaScript code:
var btn = new ToolButton;
btn.icon = ":/icons/arrow-right.png";
btn.resize( 22, 22 );
In this example we are creating a new tool button to show a "right arrow" icon. Since we know that all interface icons have 16x16 pixels, we are resizing the button to 22x22 pixels to give it a nice margin of three pixels. This works fine with standard monitors where typical dot pitch sizes are in the range from 0.22 to 0.25 mm. However, what happens on your laptop's monitor? Obviously, 16x16 is too small. So the above code could be something like this:
var btn = new ToolButton;
if ( runningOnHighDPIScreen() )
{
btn.icon = ":/icons/high-res/arrow-right.png";
btn.resize( 44, 44 );
}
else
{
btn.icon = ":/icons/low-res/arrow-right.png";
btn.resize( 22, 22 );
}
So depending on the screen resolution, the script would select the appropriate set of icons (in the example, 32x32 icons and 6-pixel margins under high dpi modes). Now imagine what this would mean for the hundreds of processes and scripts that populate PixInsight. To make things even more "interesting", consider that in the real world we would need three or four different sets of icons (typically, 16x16, 24x24, and 32x32; perhaps also 48x48). Now what happens with text rendered on interface elements, such button texts, text on item lists, title bars, etc? Although text is more manageable, mainly because we normally define text sizes using resolution-independent units (typographical points), there are also important font-related problems.
As becomes evident after a first analysis of the problem, the solution cannot be forcing developers to take into account different screen resolutions. The solution has to be transparent to all existing and future modules and scripts, requiring no source code changes, or at most slight changes in a reduced set of special cases. We have to evolve our development frameworks to start working with virtual interface units instead of physical device units (pixels), and the internal changes required to implement this efficiently are not trivial.
Sorry for the lengthy story, but this is a "hot" topic where we need our users to understand the actual dimension of the problem.
