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

The sad state of font rendering on Linux (2018)

pandasauce.org

Post reply on HN
Print view View original

101–104 of 104 posts

Re: The sad state of font rendering on Linux (2018)

#101

Post by LargoLasskhyfv »

nomel wrote: post #87
hnuser123456 wrote: post #71

Earlier quoted context omitted.

CRT resolution was moreso limited by GPUs than the monitor itself. They don't have fixed pixels like LCD/OLED.

> GPUs than the monitor itself. No, it was limited by the bandwidth of the beam driving system, which the manufactures, obviously, tried to maximize. This limit is what set the shadow mask and RGB sub pixels/strip widths. The electron beam couldn't make different color, different colored phosphor patches were used. But, since bandwidth is mostly resolution * refresh, you could trade between the two: more refresh, les…

I got a 21" Hitachi Superscan Elite or Supreme around that time from a gamer.

Because that thing could only do the BIOS text modes, and standard VGA at 640x480 at 60 or 70Hz. Anything else just showed OUT OF SYNC on the OSD, and then switched off.

Except when you fed it 800x600@160Hz, 1024x768@144Hz, 1280@120Hz and 1600x1200@70 to 80Hz, or anything weird in between.

I could easily do that under XFree86 or early X.ORG. A gamer under DOS/Windows rather not, not even with Scitech Display Doctor, because most games at that time used the hardware directly, with only a few standard options to chose from.

OUT-OF-SYNC zing

Was nice for viewing 2 DIN-A4 side by side in original size :-)

Fortunately a Matrox I had could drive that, as could a later Voodoo3 which also had excellent RAMDACs and X support.

Re: The sad state of font rendering on Linux (2018)

#103

Post by perching_aix »

LargoLasskhyfv wrote: post #101
nomel wrote: post #87

Earlier quoted context omitted.

> GPUs than the monitor itself. No, it was limited by the bandwidth of the beam driving system, which the manufactures, obviously, tried to maximize. This limit is what set the shadow mask and RGB sub pixels/strip widths. The electron beam couldn't make different color, different colored phosphor patches were used. But, since bandwidth is mostly resolution * refresh, you could trade between the two: more refresh, les…

I got a 21" Hitachi Superscan Elite or Supreme around that time from a gamer. Because that thing could only do the BIOS text modes, and standard VGA at 640x480 at 60 or 70Hz. Anything else just showed OUT OF SYNC on the OSD, and then switched off. Except when you fed it 800x600@160Hz, 1024x768@144Hz, 1280@120Hz and 1600x1200@70 to 80Hz, or anything weird in between. I could easily do that under XFree86 or early X.ORG…

That sounds weird and fun, although I can't seem to find the pattern that would have resulted in those numbers. 1024×768@144 (8bpc) works out to 340 MB/s, while 800×600@160 (8bpc) works out to just 230 MB/s, should have been able to refresh even faster. Or is that some other limitation that's not bandwidth? [0]

Was a bit surprised by that double A4 thing btw, but I did the math and it checks out - paper is just surprisingly small compared to desktop displays. Both size and resolution wise (1612×1209 would have put you right up to 96 ppi, with regular 1600×1200 being pretty close too). It's kind of ironic even, the typical 1080p 24" 60 Hz LCD spec that's been with us for decades since just barely fits an A4 height wise, and has a slightly lower ppi. Does have some extra space for sidebars at least, I guess.

[0] Update: ah right, it wasn't a pixel clock limit being ran to the limit there, but the horizontal frequency.

Re: The sad state of font rendering on Linux (2018)

#104

Post by LargoLasskhyfv »

perching_aix wrote: post #103
LargoLasskhyfv wrote: post #101

Earlier quoted context omitted.

I got a 21" Hitachi Superscan Elite or Supreme around that time from a gamer. Because that thing could only do the BIOS text modes, and standard VGA at 640x480 at 60 or 70Hz. Anything else just showed OUT OF SYNC on the OSD, and then switched off. Except when you fed it 800x600@160Hz, 1024x768@144Hz, 1280@120Hz and 1600x1200@70 to 80Hz, or anything weird in between. I could easily do that under XFree86 or early X.ORG…

That sounds weird and fun, although I can't seem to find the pattern that would have resulted in those numbers. 1024×768@144 (8bpc) works out to 340 MB/s, while 800×600@160 (8bpc) works out to just 230 MB/s, should have been able to refresh even faster. Or is that some other limitation that's not bandwidth? [0] Was a bit surprised by that double A4 thing btw, but I did the math and it checks out - paper is just surpr…

That are the resolutions and frequencies I do remember having tested without trouble. Indeed I could go even faster on the lower ones, but didn't dare to for long, because they sometimes produced very weird high-frequent noises, sometimes unsharpness, and I didn't want to break that wonderful piece of kit.

Did care about 1600x1200 at then 75Hz mostly. All that other stuff was just for demonstration purposes for other people coming by, or watching videos fullscreen in PAL.

It seemed to be really made for that resolution at a reasonable frequency, with the BIOS & VGA thing just implemented to be able to see start up, changing settings, and all the rest just a 'side-effect'.

Post reply on HN