Under CGE we;ve got e.g.RenderRect.Width and RenderRect.Height and the Lazarus Forms unit has similar facilities including PixelsPerInch.
If logging is enabled there is also a PPI value although nothing is found when searching the docs for PPI.
Of particular note is the case of mobile devices. Can we get a PPI for these and is it real (or 96?). As a mobile version of a project can potentially be run on a wide variety of devices and the resolution can be very high a real value for PPI is desirable. Text that’s legible on a tablet can become stupidly small on a phone.
There also exists the possibility of displaying some real-world object at it’s physical size in a 3D view of a scene. This specific case would rely on knowing the PPI of the device to display a realistic representation of a real-world object to scale - you’d see more of them on a larger screen for example.
It’s called Dpi,
You will usually access the 2nd one, as Container.Dpi (the Container property is both in TCastleWindowBase and in TCastleControlBase, in the first case it uses CGE CastleWindow code, in the 2nd case it uses LCL PixelsPerInch).
It works on all desktops and mobile. On desktops, the implementation was actually done looking at what LCL does. It is correct – at least as much as underlying platform APIs are correct. So when it’s not precise, you can at least rest assured that all the other applications see the same value.
- E.g. as far as I recall, it is not precise on some Android models.
- E.g. on desktops, DPI is adjustable by user (both Linux and Windows allow to change what application sees), and whether it makes any sense (whether it corresponds to real physical size) is up to user. It’s the same with LCL
PixelsPerInch.
Note 1: The question is not really related to CGE RenderRect 
RenderRect is a property available at each TCastleUserInterface, and it specifies the control size in pixels. (real final pixels, not scaled.)
Note 2: Using UI scaling is very much advised to have a good starting point for a cross-platform UI, that scales and adjusts to various window sizes and aspects. Our templates, examples all use it. https://castle-engine.io/manual_2d_user_interface.php , https://castle-engine.io/manual_castle_settings.php all use it. It’s not based on physical size, instead it adjusts itself to window sizes, scales things without distorting proportions, and relies on proper anchors to keep the correct layout. I very much advise to use it, and it was enough in all our Cat-astrophe Games games (on production, on various platforms ). This is also similar to what Unity offers.
Of course it will not address the fact that various physical screen sizes will result in various physical text sizes. If you design a text that has height 1/4 screen, it will be 1/4 height on phone, and 1/4 height in tablet, so will be physically much larger on tablet. You can indeed try to fight with this using Dpi and adjusting sizes at runtime.
But warning: counteracting this, using Dpi, is usually low-priority IMHO. It’s better to design UI that just makes sense on all platforms, using our existing scalable UI. Most games that I know of also don’t try to adjust to physical size.
Tried dpi out on Windows, Linux, Android + iOS (gonna try a Mac test next)
The value returned is pretty much useless when it comes to trying to show an image at real-world size.
iOS was easiest to sanity check as the DPIs are listed in Wiki
iPhone 6 - 1136x640 / 192dpi - wiki = 326dpi
iPad Pro - 2048x1536 / 192dpi - wiki = 264dpi
The iPhone screen size is reported scaled and all the dpi values are wrong
If I can get the Mac working that should be fun…
In the specific case of Apple it’d be possible to report an accurate fudge factor resulting in real-world scaling using a table of model vs physical screen specs - for everything else - best not even think of trying