P: SDK: LrSystemInfo.displayInfo() and .appWindowSize() return wrong units of pixels on Windows

0 Votes
Jan 31, 2022 Jan 31, 2022

Copy link to clipboard


On Windows, when the user has set Preferences > Interface > Font Size to Large, Larger, or Largest, it's impossible for plugins to properly size large controls and dialogs.  This is because LrSystemInfo.displayInfo() and .appWindowSize() incorrectly return width and height in units of physical pixels, rather than scaled pixels.  


On Mac, those functions correctly return scaled pixels, allowing plugins to properly size controls and dialogs.


Most recently tested on LR 11.1 / Mac OS 11.6.2 and Windows 10.


[This bug report is an updated version of the original posted in 2018, which never got copied to this forum:



It has been edited somewhat to reflect changes in LR in the past four years.]


On Mac, you can set a scaling factor for Retina displays via System Preferences > Displays.  Setting a scaling factor of 200% doubles the size of LR's user-interface elements.  On Windows, the user scales the user-interface elements via Preferences > Interface > Font Size; e.g. Font Size: Larger - 200% doubles the size. (The Windows display scaling affects just the menu bar.)


A number of LrView controls have width and height properties that are specified in units of scaled pixels. Scaled pixels times the scaling factor gives the number of physical pixels.

On Mac, LrSystemInfo.displayInfo() and .appWindowSize() return screen and window sizes in units of scaled pixels. This enables plugins to make a dialog as large as possible while still fitting on the screen; for example, the plugin can set the width and height of a scrolled_view() (in units of scaled pixels) to be somewhat less than the screen size (in units of scaled pixels).

But on Windows, LrSystemInfo.displayInfo() and .appWindowSize() return sizes in units of physical pixels, and there is no easy way for a plugin to get the current scaling factor to translate them to scaled pixels. This makes it impossible for a plugin to make a large window that is guaranteed to fit on the screen.


A Fix that Maintains Backward Compatibility


Correcting this bug would break existing plugins that rely on the incorrect return values from displayInfo() and appWindowSize().  Two trivial alternatives would maintain compatibility but allow plugins to properly size large windows:


- Change displayInfo() to also return fields "widthScaled" and "heightScaled", with width and height in scaled pixels. Add a new function LrSystemInfo.appWindowSizeScaled() that returns the width and height of the window in scaled pixels.


- Add LrApplication.fontSize(), which returns a number representing LR's scale factor set in Preferences > Interface > Font Size (e.g. 1.0 for "small", 2.0 for "Larger - 200%").  On Mac, plugins would ignore that, but on Windows, plugins would use it to compute the screen and app window dimensions in scaled pixels.


Demonstrating the Bug


The script below tries to create a scrolled_view() whose height is 1/2 of the screen height. On Mac, that works properly regardless of the current scaling factor, since both LrView and LrSystemInfo use the same units, scaled pixels. But on Windows, when Font Size is Larger - 200%, then the scrolled_view() is twice as large as it should be, overflowing the screen, because LrView uses scaled pixels and LrSystemInfo uses physical pixels.




local LrDialogs = import "LrDialogs"
local LrSystemInfo = import "LrSystemInfo"
local LrView = import "LrView"

local f = LrView.osFactory()
local format = string.format

local display
for _, info in ipairs (LrSystemInfo.displayInfo ()) do 
    if info.hasAppMain then display = info end
local app = {LrSystemInfo.appWindowSize ()}

local width, height = 250, math.floor (display.height * 0.5)

local contents = 
    format ("Screen: %d x %d\n", display.width, display.height) ..
    format ("Lightroom window: %d x %d\n", app [1], app [2]) ..
    format ("scrolled_view should be: %d x %d\n", width, height) 

for i = 4, 100 do contents = contents .. format ("Line %d\n", i) end

local result = LrDialogs.presentModalDialog {title = "Scaling Bug", 
    contents = f:scrolled_view {width = width, height = height,
        f:static_text {title = contents}}}




Bug Started
macOS , SDK , Windows






Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Adobe Employee , Feb 02, 2022 Feb 02, 2022
Setting status - adding bug number
Status Started



1 Comment
Adobe Employee ,
Feb 02, 2022 Feb 02, 2022

Copy link to clipboard



Setting status - adding bug number

Rikk Flohr - Customer Advocacy: Adobe Photography Products
Bug Started