Being ever so slightly two-faced.

[richmond62]

Having stated that I would stop contributing to the LiveCode forums I have just contributed something . . .

. . . No, screw it, I am not going to go in for sack-cloth and ashes . . . we do (like it or not) owe some sort of debt of gratitude to LiveCode0.

As the OP seemed . . .

LC has a way to obtain DPI (pixel density) on mobile, but I don't believe there's anything in the engine to get that info for desktop platforms. I have a case where on-screen display needs to be of a specific real-world size in inches. I can dig up the AppleScript/Powershell combos needed for stuff like that, but before I spend the time it seemed worth asking:

Anyone here seen a Builder script or other LC extension to obtain DPI for desktop monitors?

a bit, surprisingly considering who it was . . . lost with something (unless, of course, Hee-Haw, I got the thing entirely wrong) really quite simple.
-

SShot 2024-04-04 at 9.43.15.png (40.96 KiB) Viewed 210 times

[FourthWorld]

The number of pixels and the size of each pixel are different metrics.

[richmond62]

The number of pixels and the size of each pixel are different metrics.

Quite probably: although that comment brings no-one any nearer to working out DPI, so I wonder why it was necessary, unless it was just meant as the "usual squish".

ALSO; I have found another problem associated with screenRects which I have outlined in the LC Forums.

[FourthWorld]

You had described the problem as either simple or something you had misunderstood. Assuming your interest sincere, I clarified my query.

[richmond62]

Actually what I did do was point out that:

1. It was comparatively easy to find both the 'real' and the 'retina display' resolution of most monitors (c.f. the discovery I made about some monitors today).

2. What I also pointed out was that with a routine in C# one can generally find out the physical measurements of an attached monitor.

3. #2 does NOT seem possible in xTalk.

4. As a result to ascertain DPI (and it escapes me why this is so important) inwith xTalk is probably not possible.

AND what is obvious is that a 'pixel' is a rather subjective thing.

"Size-wise, a pixel is approximately 1/96 of an inch which translates to 0.26 mm. This fixed length is mostly used in graphic design, web design, and user interfaces to ensure that an element displays as the same size regardless of the screen resolution used to view it.

"Nonetheless, it is often viewed that there is no one fixed, standardized, and defined physical size of a pixel. You can calculate the size of a pixel for any display device. This is done by dividing the size of the display screen by the resolution."

THIS page seems to give a fairly clear view of pixels, 'pixels', 'pixies', and the voices in my head:

https://www.picmonkey.com/blog/complete ... 0view%20it.

NOT a pixel:
-

pixie.jpg (5.43 KiB) Viewed 160 times

-
But in some ways might be more useful than worrying about pixels.

[FourthWorld]

The definition you cite there is well known, but dependent on a piece of information not easily determined from within LiveCode: the physical screen size.

Variance in pixel density among mobile screen manufacturers is so great that LC devs couldn't plausibly produce many mobile apps without the pixelDensity function.

But given the smaller variance with desktop pixel densities, and how rare it is to need to display things at a precise physical size (in 30 years this is only the second time I've needed it), extending the pixelDensity function for desktop has been a low priority.

In its absence, the next best option is to obtain it through some external engine, either PowerShell or perhaps CSS queries in an embedded browser.

[richmond62]

C# must pick up data relating to the physical size of a VDU from somewhere: if xTalk could read that same data the problem would be solved.

And I would suppose those webpages that deliver your screen measurements are doing much the same thing.

[OpenXTalkPaul]

I thought that pixelDensity property did actually work on desktop, at least on macOS (can't check right now, will do later) which makes sense since it's probably the same API used on iOS.
Shell("system_profiler SPDisplaysDataType") I thought might get it, but that only gives the full pixel amount of the screen, but not the pixels-per-inch density (which really should depend on the Display control panel's current size setting, since the user can change that).

AMD Radeon Pro 5300:

Chipset Model: AMD Radeon Pro 5300
Type: GPU
Bus: PCIe
PCIe Lane Width: x16
VRAM (Total): 4 GB
Vendor: AMD (0x1002)
Device ID: 0x7340
Revision ID: 0x0047
ROM Revision: 113-D3220I-231
VBIOS Version: 113-D322A1XL-011
Option ROM Version: 113-D322A1XL-011
EFI Driver Version: 01.01.231
Metal Support: Metal 3
Displays:
iMac:
Display Type: Built-In Retina LCD
Resolution: Retina 5K (5120 x 2880)
Framebuffer Depth: 30-Bit Color (ARGB2101010)
Main Display: Yes
Mirror: Off
Online: Yes
Automatically Adjust Brightness: No
Connection Type: Internal

I'm certain the current PPI density could be gotten on MacOS with a little Extension Builder FFI and a bit of CoreGraphics or AVMedia API. I was looking into this previously because I wanted to know the resolution and physical positioning settings of a multiple monitors setup.

[OpenXTalkPaul]

mobilePixelDensity() -- Mobile Only
get the pixelScale -- according to dictionary is Mobile Only???
---
set the usePixelScaling to { true | false } -- mobile and desktop since v6.6
get the systemPixelScale -- mobile and desktop since v6.5
get the screenPixelScale -- mobile and desktop since v6.6
get the screenPixelScales --- plural for multiple monitors, mobile and desktop since v6.6