OS X has the best highdpi implementation at the moment, and use the pixel scaling approach. It seems to work well there.
The extent to which the third party software ecosystem supports Retina is, I think, the greatest strength of OS X at the moment.
High-DPI displays and Linux
81–90 of 106 posts
Re: High-DPI displays and Linux
#82My 12 year old irix fuel v10 that I used for my phd has full vector graphics and fonts and supports monitor resolutions much higher than I can afford/justify today.
I miss working on my irix :(
Re: High-DPI displays and Linux
#83I have a Thinkpad Yoga 2 Pro (3200x1800 @ 13"), and often use an external monitor. My "solution" is to turn off HiDPI and rely on the zoom features in all of my apps. (terminal, emacs & browsers) Browser windows on the laptop usually run at a zoom of 200%, whereas windows on the external display run at 90%. Annoying, but the beautiful text is worth the bother.
Wait, you can use the Yoga as an external monitor for another device? That's sweet.
I didn't get that from what he wrote. What I understand is that he has a Yoga and uses an external monitor as well as the Yoga screen.
Re: High-DPI displays and Linux
#84I have a Thinkpad Yoga 2 --- 3800x1800 I think --- I find that the GTK-based stuff works well on HiDPI, but not automatically, so you need to fiddle with the GTK settings a bit. The QT stuff is worse since they cannot be fixed by adjusting only the font size. The older (Xaw3D,TK) stuff is really bad. I have never seen different DPI on different displays working. 99% of my day is spent in the terminal (xfce4-terminal)…
It's 3200x1800, so that with pixel doubling you can an effective 1600x900.
Re: High-DPI displays and Linux
#85Somewhere in the 90's, games were in 320x200 pixel resolution, and the Windows 3.11 desktop was 640x480 pixels or so on a typical 386 computer. Then up to around the year 2000, resolutions increased, going through such stages as 800x600, 1024x768 and 1280x1024 (your CRT would flicker if much higher, and then LCDs came along pinning it at 1280x1024 for 17"). Then the resolution (or especially DPI) growth basically sto…
I am guessing - is it because of HDMI and its abysmal bandwidth? Before with VGA the actual resolution of CRT monitors was limited by RAMDAC. And 10 years ago I was able to to have 2048x1536@70Hz on a top-end 15" CRT already. I guess as nowadays all digital signal is routed through content protection filter, the technology processing these streams wasn't performing well, causing stagnation in display resolutions for…
A few points:
1. DVI has supported higher resolution displays for a long time; 1920x1200 since 1999 on single-link, and 2560x1500 on dual-link. Note that this is more than '10 years ago'.
2. HDMI has supported 4K displays since May 2009.
Most of your post belies a misunderstanding or underestimation of the technology involved. The bottleneck was never 'content protection filters' so much as the feasibility of building electronics that can handle higher-bandwidth signals over cables with no extra data channels (in a backwards-compatible manner), and the challenge of getting manufacturers to make hardware that would actually support it, at increased cost, for no practical benefit.
For older LCDs, it was an issue of new technology is expensive. I remember when everyone I knew had 15" CRT monitors, and having a 15" LCD monitor was a luxury that almost no one could afford. It might be hard to remember, but consumer LCD displays were new once, and new technology is never cheap. On top of that, the cost of an LCD panel doesn't scale linearly with diagonal size, so going from 15" to 17" to 19" was a huge cost curve. Until LCD production was more consistent and people understood the point in buying them over CRTs, the market didn't really heat up, and so sizes/resolutions never grew.
As for DPI, LCD DPIs depend on the size of pixels, which are a mechanical element. In contrast, CRT displays are a printed screen of phosphors; paint a smaller, more detailed phosphor grid, adjust the electronics for more precision control, and boom, higher DPI.
Re: High-DPI displays and Linux
#86Earlier quoted context omitted.
We used over 3000 minimun pixel length CRTs at work. But they were complete monsters(they were deeper than x, y dimensions), not good for your eyes either,needed filters, some X rays will hit your face. We replaced them with much cheaper(and not as good quality) LCDs arrays. They were so cheap that you could buy 6 for the price of 1 high quality display. What happened is very simple, LCD technology did not benefit fr…
It often is better to sell cheap stuff to many people, than to sell expensive stuff to a few. VW bought Porsche, Fiat bought Ferrari etc. :D
Actually, Porsche bought VW:
Re: High-DPI displays and Linux
#87Somewhere in the 90's, games were in 320x200 pixel resolution, and the Windows 3.11 desktop was 640x480 pixels or so on a typical 386 computer. Then up to around the year 2000, resolutions increased, going through such stages as 800x600, 1024x768 and 1280x1024 (your CRT would flicker if much higher, and then LCDs came along pinning it at 1280x1024 for 17"). Then the resolution (or especially DPI) growth basically sto…
Your timeline is pretty far off, to my memory. We had VGA graphics games in the early 90s. My Sparcstation 20 came with a 1280x1024 CRT monitor. The 15" Sony CRT I bought shortly after, along with a Matrox Millenium PCI graphics card, was capable of the same. I ran a 21" Sony at 2048x1536 in 1999. It did not flicker.
If he's talking about games and therefore mass market Intel micros, he's roughly right. 1990ish just-plain-VGA gives you 640x480x4bit or 320x200x8bit. You'd generally use the latter for games.
Re: High-DPI displays and Linux
#88I see that phrasing all the time: "Well, KDE can do what we are looking for, but GNOME does it in a hackish way. As we use GNOME, our review is all about it, and as a conclusion, Linux is no good." Why do these people insist on using GNOME after all?
I assume you haven't used both GNOME and KDE on a high-DPI monitor, because KDE's support for it is certainly not better. Qt themes don't scale, web views don't scale, icon, window, plasma panel, etc sizes need to be configured independently of font DPI, some applications just fritz out at high DPI font sizes. I've tested both 4.13 and 5.3, and haven't noticed any significant improvement in the latter. I'm a fan of K…
Well, I didn't. I don't have any HDPI display.
But I've seen that from people complaining about workflow, supporting non-usual options, and accessibility.
Anyway, yours is the first review I see about KDE in HDPI.
Re: High-DPI displays and Linux
#89Somewhere in the 90's, games were in 320x200 pixel resolution, and the Windows 3.11 desktop was 640x480 pixels or so on a typical 386 computer. Then up to around the year 2000, resolutions increased, going through such stages as 800x600, 1024x768 and 1280x1024 (your CRT would flicker if much higher, and then LCDs came along pinning it at 1280x1024 for 17"). Then the resolution (or especially DPI) growth basically sto…
(Not sure I 100% agree with your timing, but that doesn't matter too much...)
The last 10 years have seen a major shift from desktop to laptops (and mobile/tablet). That has different needs & constraints. e.g. Power, form-factor, capabilities of mobile GPUs. So I think that's part of the effect you've witnessed.
Re: High-DPI displays and Linux
#90OS X has the best highdpi implementation at the moment, and use the pixel scaling approach. It seems to work well there.
It does work well. The other day, there was an article on someone who did an extreme test on pixel scaling, and an Apple software engineer wrote the following comment:
https://news.ycombinator.com/item?id=8634895
The part of the comment that I found the most interesting was his take on a solution:
1. Make everything vectors. You'll have to choose between weird antialiasing artifacts and potential pixel cracks; either way things will look bad. And you'll encounter bitmaps eventually, and have to deal with the necessities of resampling and pixel aligning at that point. 2. Scale only to integral sizes, and resample. You'll avoid antialiasing and pixel alignment issues, but pay a performance penalty, and things may look slightly blurry.