Windows display scaling messes up plugin dialogs

I’m probably missing something obvious here, but I’ve just tripped over an issue drawing plugin dialogs when the Windows display scale is not 100%:
This is in the display control panel:

If that’s set to 100% then my dialogs display as intended:

If it’s at 125% (or anything other than 100%) the contents get scaled, but the dialog size does not:

I’ve tried messing with the values in the Presentation panel on the Interface pane of Photoshop’s preferences, but nothing there seems to make any difference:

I can see discussions on this forum and elsewhere about 6 years ago around something similar, but that was primarily for 4k displays; I’m just looking at 1920x1080. I tripped over this because my main (17") laptop uses 100% by default, but the lower powered 15" machine that I was using for testing uses 125% by default. The problem back then was supposedly solved.

I can’t see any way to read or even to intuit the Windows setting. core.calculateDialogSize always shows the same number (and, indeed, the displayed dialog has the same dimensions. I can’t see how I could reliably get any info from core.getDisplayConfiguration.

Am I missing anything here?

FWIW, I wouldn’t change my 15" laptop to 100% scaling because that makes menus etc too small to read, so I don’t think it’s reasonable to tell users to do that.

A quick update.

In theory window.devicePixelRatio should give me the scaling factor I need. But it sometimes returns 1 when is should be 1.25 or whatever. Reloading the plugin while the OS has a scale factor applied seems to be the most obvious cause.

So then I looked at core.getDisplayConfiguration({}), and specifically the scaleFactor in one of the array elements returned. That seems to be consistently correct, but more testing on more physical monitor setups is required. I don’t know if that might be different for each monitor, and, if so, how to choose which monitor.

On the assumption that that is reliable, I can then scale the dialog height and width appropriately and everything should be OK.

Except that I also need to ensure that the outermost div on every dialog has an absolute width, otherwise any children using % widths (either stand-alone or in calc functions) try to fit themselves to the scaled up dialog width instead of the original design width.

I still have a niggle on height that I haven’t pinned down, but I think I’m getting there.

Just for fun, this is what I get for a setup with a 15" 1920x1080 laptop, a 4k external monitor and a larger 1920x1080 monitor in portrait mode:

[
  {
    "globalBounds": {
      "bottom": 1080,
      "left": 0,
      "right": 1920,
      "top": 0
    },
    "globalWorkingBounds": {
      "bottom": 1020,
      "left": 0,
      "right": 1920,
      "top": 0
    },
    "isPrimary": true,
    "scaleFactor": 1.25
  },
  {
    "globalBounds": {
      "bottom": 1625,
      "left": 1920,
      "right": 5760,
      "top": -535
    },
    "globalWorkingBounds": {
      "bottom": 1553,
      "left": 1920,
      "right": 5760,
      "top": -535
    },
    "isPrimary": false,
    "scaleFactor": 1.5
  },
  {
    "globalBounds": {
      "bottom": 1432,
      "left": 5760,
      "right": 6810,
      "top": -248
    },
    "globalWorkingBounds": {
      "bottom": 1384,
      "left": 5760,
      "right": 6810,
      "top": -248
    },
    "isPrimary": false,
    "scaleFactor": 1
  }
]

As you can see, each of the three displays has a different scaleFactor.

I’ve been revisiting the question of how to work out which one the dialog is currently displayed on, given that the user can, of course, drag it from one to another. If I could get an absolute location for it then I could compare with the bounds info above, but I haven’t managed to find anything.

I’m starting to wonder if I will need to offer the user the option to tell the plugin which display the dialog is on, but that seems very kludgy. I’m not even sure how to map the order in the array above to anything that the user might recognise. Sigh.

What if you would extra empty space to the sides of dialog so it would always fit? :smiley:

Or if you can determine dialog position in advance… could show same dialog on all screens at the same time so user would not need to move it away? :smiley:

btw has built-in alert dialog same issue? Or other built-in dialogs they have in 1st party plugins?

The standard Windows display scale factors go up to 175%, so you’d need to make the dialog at least 1.75x as wide as you really want it to leave space on the side and the bottom. Not really feasible when my dialog is already probably a bit too big anyway.

You can even do custom scale factors up to 500%, but at least then it sets the same factor on all monitors. And it recommends very strongly against using that capability. It’s the strongest warning I’ve ever seen from Microsoft saying “here’s a gun, please don’t point it at your head”.

If you take my 3 display system as listed above I can’t see it making sense to show the same dialog (with different scale factors) on all three screens, and then synchronising changes across them. If I were using somebody else’s software and they did that it would get uninstalled in double-quick time!

Built-in alerts, and even all my other modal dialogs, don’t suffer from this problem because I leave Photoshop to calculate width and height automatically. My primary settings dialog does suffer because I set the dimensions manually, and that’s so I can handle accordions, with sections collapsing and expanding. Photoshop doesn’t amend the dialog height after the first time it draws it, even if the contents change.

Hmmm, I find myself wondering if this might be similar to changing values in sp-menu. Doing that doesn’t get the menu redrawn, but if you rebuild the entire sp-picker it does.

I’m off to find out what happens if you don’t explicitly set dialog dimensions, but you replace innerHTML, or even outerHTML on the dialog element. Will it redraw the dialog and recalculate the size?

I’ll be back later!

(oh, and I have no idea yet how any of this behaves on Mac; that’s a joy for another day)

– later –

You can’t replace outerHTML on a dialog because it has no parent, but I could replace innerHTML with a slightly altered copy of the original.

That makes life interesting because it wipes out all of the event handlers, because all of the buttons etc are now new, not the same elemnts as they were before.

But I fiddled enough to allow me to change a check-box that closed an accordion … That bit worked, but it did not automatically recalculate the dialog height.

Hmmm

1 Like

I’ve spent more than enough time on this; I’m giving up and removing my accordions so I can just let Photoshop set the dialog sizes.

I believe that this is a long-standing bug in Photoshop (exacerbated by a long-standing inability to work out which monitor a dialog is displayed on), but given that most people have concluded that you can’t control dialog sizes anyway, I can see why it’s probably quite low on Adobe’s priority list.

Life’s too short, moving on.

1 Like