Xlib: DisplayWidth / DisplayHeight

[Vladimir Dergachev]

On Wed, 30 Aug 2023, Zbigniew wrote:

>>>       „The  DisplayHeight  macro returns the height of the specified
>>> screen in
>>>       pixels.
>>>
>>>       The DisplayWidth macro returns the width of the screen in pixels.”
>>>
>>> This is what I want, and this is what — as „man” page states — I
>>
>> And this what you get. Now when I say "Screen" I mean large rectangular
>> matrix of pixels I can paint on. Which is pretty much what any application
>> cares about - you don't need to paint outside of screen.
>
> Dear, if we should mean by „screen” just any „large rectangular matrix
> of pixels we can paint on” — then the whole discussion has no sense
> whatsoever, and I should IYO be pleased, that the two functions return
> to me, well, anything at all. Just in such case — you forgot(?) to add
> — the use of the functions, that return „just something”, has no
> purpose.

It's a reasonable thing to do, see below.

>
>> What do you mean by "Screen" and why ?
>
> You already know, what I mean — since you've already guessed it: the
> physical screen I have. Why? Because that's the area where the window
> of my program will appear.
> What makes you think, that the creators of these functions, when
> designing them years ago, meant anything different at that time, than
> „resolution of physical screen handled by its Xserver”?

This shows the differences in education back then and now.

What people used to do when writing programs (as opposed to "software") is 
to create a mathematical model first, and then implement it. And when you 
used a piece of technology you would read the manual and make sure you 
knew the definitions of all the technical terms used.

The mathematical model of the physical display chosen for the Xserver was 
a rectangular array of pixels and this is different from vector displays 
also used at the time.

I don't actually know whether the the first Xserver supported panning but 
it was added shortly after because the screens back then typically had 
very small resolutions - even in the 1990s that were mentioned earlier 
1280x1024 was a high-end display. Panning was commonly used, and it was a 
welcome feature that the applications could not tell that the actual 
display is much smaller.

Now, the Xserver back then only supported one physical display per 
abstract screen, of which there could be several. This quickly evolved as 
people wanted to move windows from one display to another - separate 
screens do not allow that, because the application gets a screen number 
from the Xserver when it opens a window and that fixes the screen it can 
paint on.

So nowadays we have xrandr and it works amazingly well. And it has the 
same paradigm - one big virtual screen, parts of which are made visible on 
physical displays, but now there could be more than one physical display.

I'll let other people chime in (if they want) on how all of this looks 
when you are running a compositor - when applications render off-screen, 
or with newer Wayland.

The cool thing however, is that I can launch xeyes and it works just the 
same as when it was created decades ago. This is because people back then 
thought through the mathematical model of what they are doing, and did not 
just "softwared" their way to a kludge that needed compatibility breaking 
changes every year the way python does.

best

Vladimir Dergachev

> -- 
> regards,
> Zbigniew
>