Pixel Pitch Function (mm global units, round down to closest integer pixel)

[Emptyself]

Questions possibly related to:
HDPi
Display Driver
Hardware info, reported by the OS (Operating system)

I am unexperienced in computer programming… maybe just after "Hello, world!", if I do not forget «;».

I want all my GUI and text based (terminal) interfaces to be based around the simplest form of reading: TEXT (typeface\fonts)
UI icons can be only Font–based or .svg (vector)
no raster icons (.png, .jpg, .bmp, …)

I need my code to get the Pixel Pitch tech. info\value for the current monitor, where my current window (Form) is.
Then to have a 'Pixel Pitch' related function to adjust all or any of the UI elements, with Default value equal to the so called «Zoom 100%»
I want to work in millimeters [mm], not in pixels, not in dots, not in em–space… because I do not care what the display's PPI (PPcm) is.
I want this function to also «bypass» any OS related 'Scaling %' and such nonsense.

A minimum requirement for a pleasant readability of a text is the Capital letter to be 3mm, small letter to be 2mm.
If the monitor has «big pixels» then obviously The Function should give fonts used a minimum of 12 pixels (min. for Pixel Pitch of 0.233mm) or maybe 14 pixels for "average" 24" desktop monitor 1920×1080 pixels as shown below.

So, how can I write such Function in Pascal using Lazarus… and why it has not been done already?



Examples:

[KodeZwerg]

I want to work in millimeters [mm], not in pixels, not in dots, not in em–space… because I do not care what the display's PPI (PPcm) is.

That is not how Computers work, since everything what you see on a screen is scaled via DPI.

[Emptyself]

I beg to differ.

Pixels should be only for «integer correction» and absolute reference.

I want to dismiss the «pixel density» factor (depends on Pixel Pitch hardware constant!), of course and also taking into account some "border" conditions (again related to physical size of pixel… in this case if pixel size\pitch is greater than ⅓mm).

I see it this way:
get PixPitch of active monitor displays [PP1, PP2 etc.]
on which monitor\s is 'Form' «window» at any moment (tracking)?


PPFunction should act as a simple 'both way' convertor of [mm ←→ px] with integer round down to pixel und a float round down to 0.25mm (⅟₄mm).

Then. if I have FHD «1920×1080» (p\mm rounded for our Function is 3p\mm, from 36p\cm) monitor and a 4K monitor «3840×2160» (p\mm rounded is 6p\mm, from 63p\cm), then an «icon» of size 5×5mm should take 15×15 pixels and 30×30 pixels respectively.
Then inside that «icon» the text should resize accordingly… pets say with 1mm padding on each side… thut is 3p uand 6p respectively for each of the above monitors.

Text, fonts (terminal\console windows) are also GUI!
I have also came up with a name for this function: Fixel

For example, my Dell 2K (UHD) monitor has a Pixel Pitch of 0.233mm physical dimensions (42p\cm ≈ 4p\mm)!
width is 2560 pixels or 2560*0.233 = 596.48mm
596/5 = 119 icons (20×20 pixels) with min. size «readability» of 12p or 14p for text\font based GUI.

119*20 = 2380p but our monitor has 2560p width → 180p left
180p /20 = 9 «icons» of the same min. size
total of 128 «icons», though we can use that space for grouping\separation

That is how I want to do it.

[KodeZwerg]

on which monitor\s is 'Form' «window» at any moment (tracking)?

Code: Pascal  [Select][+][-]

1.     Label1.Caption := Format('Monitor #%d: %d x %d @ %d',
2.       [Screen.Monitors[Screen.MonitorFromWindow(Self.Handle, mdNearest).MonitorNum].MonitorNum,
3.        Screen.Monitors[Screen.MonitorFromWindow(Self.Handle, mdNearest).MonitorNum].Width,
4.        Screen.Monitors[Screen.MonitorFromWindow(Self.Handle, mdNearest).MonitorNum].Height,
5.        Screen.Monitors[Screen.MonitorFromWindow(Self.Handle, mdNearest).MonitorNum].PixelsPerInch]);

Maybe like that?... but i guess there are better ways.

[MarkMLl]

I beg to differ.
...
I see it this way:

Tough. You've already said that your experience is limited, so listen to KodeZwerg who's got rather more.

There's really two things here. The first is that the operating system will have its own facilities for displaying icons etc., and for performance reasons you'll find that much of that sort of thing is precomputed for "popular" sizes- 32x32, 48x48, 64x64 etc pixels... and you've not even bothered to tell us what OS you're running.

Second, while OSes typically do try to have at least some awareness of DPI (pixels per inch etc.), if that's to be accurate it relies on the display device reporting its characteristics accurately... and since many devices particularly those at the lower end use commodity controller boards without configuration to suit the physical LCD panel etc. the reliability of that is limited.

Now there's a couple of ongoing projects which attempt to reimplement a graphical subsystem on top of (basically) just a bitmapped display, and you could probably tweak those to suit the /measured/ (as distinct from reported) properties of your display device. But at best, you'd end up with application programs that looked like something from the 1980s, when practically every display library had its own visual style.

So, I'm sorry to be negative and to have started off my response appearing to be downright hostile, but rather than writing science fiction you need to come to terms with the fact that the writers of the major widget sets- MS, Apple, and the GTK and Qt developers- do generally have some idea of what they're doing and don't go out of their way to be gratuitously awkward and inflexible.

You will, of course, be able to find counterexamples: programs which "do their own thing" and still don't look too bad (things like Blender spring to mind, which at least in their early versions are forced to break new UI ground). But by and large you're stuck with the facilities that Lazarus (not to mention Delphi, Visual BASIC and so on) provide, and while these have matured to the point where you can lay out predefined widgets that autoscale in placement and size fairly painlessly, doing the same for the /content/ of the widgets (i.e. the precise size of every checkbox, caption and so on) is by and large infeasible.

MarkMLl

[J-G]

That is how I want to do it.

Well you can't !!

I've recently done quite a lot of work in this area and found that Windows 'lies' about the DPI though it does return the correct V & H pixels.

I needed a means by which the image on the screen and that output to a printer were genuinely 100%.  To do so I had to write a routine to [Calibrate] both Screen & Printer. This requires interaction from the user of course.
For the screen;
detailing the physical size of the Monitor or the pixel size specified by the manufacturer
for the printer;
feedback of physical size of the image printed.

On my main PC

Code: Pascal  [Select][+][-]

1.   ScreenPPI.Caption:=IntToStr(Screen.PixelsPerInch);

returns '96' but I know that the real PPI is 86.999.

[Emptyself]

Well, to say I am a bit disappointed (and discouraged to learn how to code) would be too optimistic.

I can not believe such a simple (and obvious!) thing has to be so complicated.   

I wanted to learn how to code (Pascal ln Lazarus) by solving this problem I encountered, whilst conceptualising my application.

I just want to base all my design around text\font\.svg elements and «bounding box» sizes. with maximum working area on the screen.

I use Windows 10 Pro. From a first glance though it seems Linux has better handling for such concepts, but I am more familiar with Windows. Thought Pascal ln Lazarus could help me get this done and thus learn how to program.

So disappointing  :'( really…

[MarkMLl]

Well, whatever you're trying to do it's not going to be easy... at least by today's standards.

OK, so blue sky ideas: you could start off by obliging the user to measure his screen: somebody else was discussing something like that a few days ago, but in his case it was- IIRC- because he had (loosely, reading between the lines) medical or assistive requirements.

You could write, from scratch, a completely new widget set: i.e. the complete collection of dialog(ue) boxes, controls and groups thereof, and so on. To get anything like the functionality you want from scratch, that's going to take several man-years.

And you could redo all text handling using e.g. Hershey fonts. But those were really targeted at vector displays and plotters, and you would find it extraordinarily difficult to get anything like the standard you get with conventional text rendering because of the amount of "hinting" built into modern typeface descriptions..

And at best, after years of work, you'd end up with something which was criticised mercilessly since like Java it didn't really look /right/ when run on a current computer.

I sympathise. My own belief is that the industry would have been far better off sticking with text-based screens for another decade or so, but the lure of WYSIWYG wordprocessing and the lack of major TUI development tools with anything like the capabilities of VB and Delphi effectively put paid to that.

MarkMLl

[KodeZwerg]

Well, to say I am a bit disappointed (and discouraged to learn how to code) would be too optimistic.

Okay, you can.

I can not believe such a simple (and obvious!) thing has to be so complicated.   

Because you thinking it in a wrong way. Millimeters you have on a paper but not on displays. Programs like Photoshop are simple lying to give you a feeling about having "real" mm measurement.

I wanted to learn how to code (Pascal ln Lazarus) by solving this problem I encountered, whilst conceptualising my application.

Concept of code (Software) and concept of Hardware are two things.
Concept of code I showed you already but you somehow ignore it. Thats fine for me.

I just want to base all my design around text\font\.svg elements and «bounding box» sizes. with maximum working area on the screen.

And you can after you have understand how a display and a graphic-card is working together.

I use Windows 10 Pro. From a first glance though it seems Linux has better handling for such concepts, but I am more familiar with Windows.

With your windows experience tell me, at which place does windows tell you the matrix/raster of your internal display?
When managed that, you still need to deal with a graphic drivers dpi configuration.
When you got that both together, you finally can "compute" but anyway, your way of how you think that things should happen is wrong.

[Emptyself]

OK, seems we have started to overcomplicate things.

Questions:

1. can we get\ask the display driver\firmware to report the Pixel Pitch physical distance in mm, like we can do that for the resolution in pixels
• I strongly believe that Pixel Pitch physical distance is a constant, otherwise the screens would have appeared wonky
• thus this Pixel Pitch physical distance constant value for each active display should be somewhere and accessible!

We need such a PPFunction {Fixel} as you can see below!
Such function should depend on PixelPitch and ultimately to recommend min. initial value for font height on the current screen.

[KodeZwerg]

Answers to your picture not your written text.

Q:"...add buttons..."
A: you need to change to borderless design of the form and create your own caption what emulate first of all the given basics (min/max/close/doubleclick/dragdrop etc)
    - the "basic" caption is controlled by the operating system and not by the programmer

Q:"...not a function..."
A: Because you are not in a font property. Reading a manual might help. The key F1 can also be sometimes like magic.

[Emptyself]

I can not believe such a simple (and obvious!) thing has to be so complicated.   

Because you thinking it in a wrong way.

I wanted to learn how to code (Pascal ln Lazarus) by solving this problem I encountered, whilst conceptualising my application.

Concept of code I showed you already but you somehow ignore it. That's fine for me.

I use Windows 10 Pro. From a first glance though it seems Linux has better handling for such concepts, but I am more familiar with Windows.

With your windows experience tell me, at which place does windows tell you the matrix/raster of your internal display?
When managed that, you still need to deal with a graphic drivers dpi configuration.
When you got that both together, you finally can "compute" but anyway, your way of how you think that things should happen is wrong.

Hi, KodeZwerg
I did not ignore it, I simply do not understand it. OK… it seems it is English based but that's all I can get from it.

And no, I do not think I am thinking it wrong.
Resolution chosen should not affect my {Fixel} function. That is why it is called {Fixel} because it fixes a min. size of all text for readability. Then the user could simply increase it by ⅟₄mm (which would evaluate to 1p at least or 2p for 2K\4K monitors, maybe 3p for 8K and especially for mobile phones with high density pixels).

Let's say my monitor is 4K. But I run it at «1920×1080».
Nothing should change to the {Fixel} size of all tex\font based non–raster UI elements, panels, form fields, etc.!
Such scale of resolution should only affect pixel based raster data\photos\textures\etc.

[Emptyself]

Q:"...not a function..."
A: Because you are not in a font property. Reading a manual might help. The key F1 can also be sometimes like magic.

I do not want to change that font size though. I want the box of that drop down menu to respect the chosen font size.

The tiny font in that info window probably can be increased somewhere in the Lazarus' settings, but I have much more crucial problem as explained in the OP (original post).

[domasz]

How about % instead?
Assume 100% = Screen.DesktopWidth, so Ratio = Screen.DesktopWidth / 100;

If an element is supposed to be 5% x 10% in size then you just multiply
5*Ratio x 10*Ratio.

[Emptyself]

How about % instead?
Assume 100% = Screen.DesktopWidth, so Ratio = Screen.DesktopWidth / 100;

If an element is supposed to be 5% x 10% in size then you just multiply
5*Ratio x 10*Ratio.

% are not very user friendly

I am really OK with [mm] as they are good to visualise ½, ⅓, ⅟₄, even a tiny ⅟₅mm as well.
For example my 12 years old 2K Dell has PP (Pixel Pitch) of about 0.233mm (roughly ⅟₄mm)
There might be some 24" 2K monitors (ViewSonic VG2455-2K 2) with PP of 0.2~0.205mm (quite exactly ⅟₅mm)…

It is really convenient to use [mm] for the function I want to have in my application.

I think GPU should not make any scaling to such {Fixel}ed objects or rather treat them as being always in native display resolution.
Because that is what this function will ask for as info: the PP (physical) of the current monitor hosting my current Form\window.