Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ancient X11 scaling technology

flak.tedunangst.com

Post reply on HN
Print view View original

231–240 of 264 posts

Re: Ancient X11 scaling technology

#231

Post by rbanffy »

AlienRobot wrote: post #224
rbanffy wrote: post #208

Earlier quoted context omitted.

It happens. You might push a window aside so that it's partially on a second screen and still see activity on the second screen. It should be the expected behavior.

I'm not saying it doesn't happen. Of course it will happen. I'm just saying it isn't something that needs to be handled perfectly, specially when handling it perfectly requires immense design changes at a fundamental level. Why can't you just display a blurry rectangle until the mouse cursor goes to the other screen and then you switch the primary resolution from one screen to the other? I feel like trying to be extr…

> Why can't you just display a blurry rectangle until the mouse cursor goes to the other screen and then you switch the primary resolution from one screen to the other?

In that case, the approach taken in macOS is nicer - it just hides the half of the window where the pointer wasn't when the window was dragged. While dragging it does a resample of the bitmap to the screen where that part is shown.

Re: Ancient X11 scaling technology

#232

Post by account42 »

kelnos wrote: post #151
amiga386 wrote: post #90

It's not "can you provide the screen DPI to a window?" people bemoan, it's "can you draw one window across two screens with differing DPIs, transparent to the application?"

You can absolutely do that on X11, but you have to do it in the client, and no one cares to do it.

No, you can't have a window with a different pixel size on one screen and another. Trying to emulate this using two windows would not achieve a smooth experience.

OTOH it is questionable if this is really all that important. Most of the time if a window spans more than one screen it's temporary because you are just moving the window from one screen to another.

Re: Ancient X11 scaling technology

#233

Post by account42 »

purerandomness wrote: post #226
rwmj wrote: post #181

Earlier quoted context omitted.

I have never had a window open across two screens if I could help it. Complete non-problem.

If you have more than one display, and you want to be able to drag windows from one to another and want them to have a similar size after dragging, it's a hard problem.

Not really, just have the window scale for one of the screens it covers.

Re: Ancient X11 scaling technology

#234

Post by account42 »

kvemkon wrote: post #44
sho_hn wrote: post #33

Earlier quoted context omitted.

It's actually a somewhat bad and uninformed post, or perhaps the mistake (unclear whether knowingly or not) is to disprove a claim made by uninformed people. No one with a good grasp of the space ever claimed that it wasn't possible on X11 to call into APIs to retrieve physical display size and map that to how many pixels to render. This has been possible for decades, and while not completely trivial is not the hard…

> to disprove a claim made by uninformed people KDE developer wrote recently: > X11 isn’t able to perform up to the standards of what people expect today with respect to .., 10 bits-per-color monitors,.. multi-monitor setups (especially with mixed DPIs or refresh rates),... [1] Multi-monitor setups are working since 20+ years. 10 bits are also supported (otherwise how would the PRO versions of graphic cards support t…

Ironically, when I tried to set my X11 to 10bpp, KDE was the main thing that shat itself while other (i.e. OpenGL-based) programs rendered correctly.

Re: Ancient X11 scaling technology

#235

Post by BearOso »

zozbot234 wrote: post #103
BearOso wrote: post #93

Earlier quoted context omitted.

I think having any kind of "scaling" preferences focuses too much on the technical aspect. It could be narrowed down to one setting like "zoom level" or just "size." This would mean that all UI elements change size exactly proportionately to one another. Ideally, rendering should happen at the exact resolution of the display, and scaling, as in resizing a bitmap using bilinear interpolation or whatever, doesn't need…

> Windows mostly does this, too, even with win32 as long as you're using the newer themes. Win32 controls have always been DPI independent, as far back as Windows 95. There is DPI choice UX as part of the "advanced" display settings.

Yeah, I'm aware it always used font units for sizing. I'm referring to the actual drawing code. Classic used single pixel lines. XP through 7 used 8-way sliced bitmaps. Windows 8 and above's simple flat theme renders everything to scale correctly.

Re: Ancient X11 scaling technology

#236

Post by account42 »

sho_hn wrote: post #52
kvemkon wrote: post #44

Earlier quoted context omitted.

> to disprove a claim made by uninformed people KDE developer wrote recently: > X11 isn’t able to perform up to the standards of what people expect today with respect to .., 10 bits-per-color monitors,.. multi-monitor setups (especially with mixed DPIs or refresh rates),... [1] Multi-monitor setups are working since 20+ years. 10 bits are also supported (otherwise how would the PRO versions of graphic cards support t…

Nate (the author of the blog post you linked), who I know personally very well, is a QA/product person focused on integration and fit and finish issues. What he means to say is that as a polished product, this is now available in the form of a Wayland-based desktop session without fiddling, while the same cannot be said of X11-based ones. It's meant as a pragmatic take, not as a history lesson. That's quite similar t…

Well the pragmatic take of many users (myself included) is to stick with X11 because Wayland absolutely is not a polished product and likely won't be before being declared obsolete by the NIH crowd.

Of course, newer KWin versions also add many odd issues with X11 so I'm sure they will bug equally buggy soon enough and users can finally switch without such concerns.

> The most close analogue I can think of that most in the HN audience are familiar with is probably the Python 2->3 transition and decision to clean thing up at the expense of backward compat. To this day, you will of course find folks arguing emotionally on either side of the Python argument as well.

Yes, that was and still is a huge clusterfuck and prime example of things not to do - precisely because it is full of completely arbitrary compatibility breaks.

Re: Ancient X11 scaling technology

#237

Post by account42 »

jchw wrote: post #61

Sigh. And now that it's been long enough, everyone will conveniently forget all of the reasons why this wound up being insufficient, and think that all of the desktop environment and toolkit developers are simply stupid. (Importantly, applications actually did do this by default at one point. I remember a wonky-looking nvidia-xsettings because of this.) The thing X11 really is missing (at least most importantly) is D…

Applications (or rather UI toolkits) need to handle scaling no matter what if you want a crisp result without giant intermediate renders. Figuring out the scale is the easy part as the article shows.

> Worse, they have to do it per monitor, and can't do anything about the fact that part of the window will look wrong if it overlaps two displays with different scaling.

That is not a real issue. Certainly not anything worth breaking backwards compatibility and even if you care about cosmetic issues like this you can fix them with extensions.

Re: Ancient X11 scaling technology

#238

Post by atq2119 »

rusk wrote: post #168
atq2119 wrote: post #118

Earlier quoted context omitted.

I'm certain that web style scaling is what the vast majority of desktop users actually want from fractional desktop scaling. Thinking that two finger zooming style scaling is the goal is probably the result of misguided design-centric thinking instead of user-centric thinking.

> misguided design-centric thinking More like “let the device driver figure it out” - Apple is after all a hardware company first.

In terms of how its business works, Apple is primarily a fashion company.

A deeply technical one, yes, but that's not what drives their decision making.

Re: Ancient X11 scaling technology

#239

Post by nullc »

kllrnohj wrote: post #146
nullc wrote: post #108

Earlier quoted context omitted.

> Yes, it was slow, Not particularly if you are on a low latency network. Modern UI toolkits make applications way less responsive that classical X11 applications running across gigabit ethernet. And even on a fast network the wayland alternative of 'use RDP' is almost unusable.

the approach used in this blog post requires rdp. It's not drawing using X, so there's no vector network transparency.

For whatever reason X11 shoving pixbufs over the network seems to have orders of magnitude better performance than actual RDP over a high speed network.

Re: Ancient X11 scaling technology

#240

Post by account42 »

jchw wrote: post #74
zozbot234 wrote: post #68

Earlier quoted context omitted.

> can't do anything about the fact that part of the window will look wrong if it overlaps two displays with different scaling It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. Generally speaking, a window will only ever span a single screen. It's convenient to be able to drag a window to a separ…

> It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. If you have DPI virtualization, a very sufficient solution already exists: pick a reasonable scale factor for the underlying buffer and use it, then resample for any outputs that don't match. This is what happens in most Wayland compositors. Ex…

> If you have DPI virtualization, a very sufficient solution already exists: pick a reasonable scale factor for the underlying buffer and use it, then resample for any outputs that don't match.

That's a shitty "solution" that doesn't even solve the issue - the result will still look bad on at least one monitor and you're wasting energy pushing more pixels than needed on the other one.

Post reply on HN