matlab gives wrong graphical display info

my laptop have a square pixels.

when i use the groot function to get the screen pixels per linear inch (PPI) and the screen resolution,

i get PPI=96 and screen resolution=1536 x 864 px,

screen width length in inches=screen width resolution/PPI=1536/96=16 inches.

screen height length in inches=screen height resolution/PPI=864/96=9 inches.

while measuring my screen size by PHYSICAL ruler results, screen size=13.4 x 7.7 inches roughly.

can anyone tell me why matlab gives me this results?

beside i figured out how to measure screen pixels per linear inch or (PPI) PHYSICALLY by capturing an image of the laptop screen next to ruler and find how much pixels there is in one inch and roughly the result was 140 pixels per linear inch, (i did this step alot of times and i am confident of that value).

finally using my results

PPI=140

screen width=13.4

screen height=7.5

resolution=1876 x 1078 px, subjected to some error of course.

which is very close to my native resolution 1920 x 1080 px which i saw it printed on my laptop specs sheet.

no matter the way i looking at the problem matlab seems to give me some wierd results please i need a full explaination for this because i want to do some GUI resizing stuff.

Answer 1

[Walter Roberson]

https://www.mathworks.com/help/matlab/creating_guis/dpi-aware-behavior-in-matlab.html

[Osama Alkurdi]

i read the doc many times and i dont get the point, can you explain it in a simple way please, thanks in advance.

[Walter Roberson]

can anyone tell me why matlab gives me this results?

The above documents the behaviour. It is not a bug, it is deliberate.

Why ??

It is because humans use graphics for multiple reasons.

• More pixels => potentially more useful information can be presented at a time. For example my 2560 x 1440 can simultaneously present literally 4 times as much information as a 1280 x 720 display. If 1280 x 720 is considered to present a usuable "page" of information, then my monitor could potentially be considered to present 4 "pages" simultaneously.
• More pixels per inch => higher resolution plots and images, for smoother-looking curves and characters, useful anti-aliasing. If you use the same physical output size for an image and you have enough data, then displaying the image at twice the resolution can make for a better-looking image, better-looking color, and less eye fatigue.

But... if you take an element such as a character, and you want it to be as readable from the same distance as before, then if you use twice the resolution, you need to use twice as many pixels wide for it. When it comes to reading text, you can get away with shrinking the physical dimensions to some extent if you can display it with sufficiently high resolution, but it becomes harder and harder to read. Comfortable reading requires a minimum angular resolution rather than a minimum number of pixels. My cell phone is over 550 dpi on a screen 2 inches wide: a 12 pixel-wide font would be only about 1/2 mm wide, which is not comfortable to read.

Thus, when you are talking about drawing something for over-all effect, like an image or a graph, then if you have enough data, you would prefer to draw it at the highest resolution practical within your response-time bounds. 150 pixels out of an image that is 4000 pixels wide might very reasonably pack down to 1/12 inch wide for the purposes of some presentations.

But when you are talking about drawing something that needs to be precisely distinguishable to the human eye, such as text, then you need a minimum angular resolution. You might need 1/12 inch per character... so like 150 pixels wide per character at the resolution of my cell phone. But only 9 pixels at the resolution of my desktop display.

You run into continued confusion over mixing these two sizes, and it gets very very common for software to not have been designed for possibilities such as characters that are individually 150 pixels wide.

In theory the way to handle this would be for programmers to have consistently used a unit of "points" for text... along with there being easy ways to query how much space a particular piece of text was going to need to render... along with policy-based positioning so you could easily program in things like "If there is enough width available for three columns given these header strings, then put up three side-by-side columns, but otherwise put up two columns and put the third one underneath the left column." But those kinds of things did not get implemented and would require significant redesign of a lot of historical graphics. (The programs would be improved by so doing, but it is a non-trivial amount of work to design something to look good on an old lower-resolution monitor and a new high-resolution monitor.)

So... Mathworks decided to compromise by talking about virtual resolutions of 1/72 (Mac) or 1/100 (Windows) pixels per inch that it then maps onto the actual resolution.

If you double the resolution, do you want two pages side-by-side, each physically smaller? Sometimes you do want that, like showing multiple images for comparison. So sometimes if you had programmed "100 pixels" then you want that to stick with 100 physical pixels even as the physical pixels get smaller (or very small!) . But a lot of the time when you double the resolution you need to keep the text much the same physical size.

These are conflicting requirements, and there is no one solution: which is the "right" one to use can depend on the user's intention at the time and can even differ from figure to figure...

[Charles Greenspon]

For what it's worth, though I understand the desired here, because the pixel scaling is explicitly incorrect for some monitors it means that if you define the position in any unit, when it shows up on your screen it just isn't accurate. It's all well and good to say that it's the same when you export it but that not exactly ideal for rapid iteration and making nice figures.