| |||||||||||||
Constant UI responsivenessConstant UI responsivenessPosted Feb 27, 2009 4:42 UTC (Fri) by eru (subscriber, #2753)In reply to: CrunchBang Linux 8.10 by proski Parent article: CrunchBang Linux 8.10 Perhaps users have become less tolerant to slow computers. Subjectively, the responsiveness of desktop operations has remained about the same, despite hugely growing memory and CPU power... As I noted in an earlier comment to a similar thread, back in around 1995 I used to run OS/2 Warp on a 75Mhz Pentium with 32MB, it was about as user-friendly as today's Linux desktops, and did not feel any slower. Unlike Windows at the time, OS/2 was a proper multitasking 32-bit OS, and its GUI was smarter. It really is a mystery where all that computing power disappears.
(Log in to post comments)
Constant UI responsiveness Posted Feb 27, 2009 7:22 UTC (Fri) by nlucas (subscriber, #33793) [Link]
Anti-aliased fonts, for starters..
Constant UI responsiveness Posted Feb 27, 2009 8:14 UTC (Fri) by eru (subscriber, #2753) [Link] Anti-aliased fonts, for starters..OS/2 already had scalable fonts (Adobe's font manager), not sure how much antialiasing would add to that. It is true my old machine had a 8-bit-colour display and the resolution was 800x600, if I recall correctly. Compared to it, my current 24-bit, 1280x1024 pixel display needs about 10 times more memory for the display. Possibly many off-screen copies of images like icons etc. have with a similar ratio. But I don't think that alone would justify all of the increased RAM requirement.
Constant UI responsiveness Posted Feb 27, 2009 9:03 UTC (Fri) by farnz (guest, #17727) [Link] When doing your calculations, remember that anti-aliasing increases the number of pixel values to calculate, and adds a stage to reduce back down to the physical pixels. In a TV targeted font rendering system I worked with, the manufacturer estimated that they calculated 16 logical pixels for every physical pixel. Responsiveness has improved for me (although I've been buying more expensive machines over time), but I've also gone from 800x600x8bit (so just under 500kiB of frame buffer to fill) to 1440x900x32bit (so nearly 5MiB of frame buffer to fill), and switched on anti-aliasing, driving the new figure up to 40MiB of pixel data to calculate in the worst case, assuming the numbers from my past still apply. The big difference I've noticed is not responsiveness when idle (which has always been beyond my ability to measure), but responsiveness under load. Instead of having my machine grind to a halt for 30 seconds when I print a photo, or compile software, I get to continue working unaffected, and background tasks complete faster - this is a win/win for me.
Constant UI responsiveness Posted Feb 27, 2009 9:10 UTC (Fri) by nlucas (subscriber, #33793) [Link]
By being anti-aliased it means they have to "alpha-blend" the character bitmap with the background and foreground color, which is several times slower than the simple case they had to do before. I don't believe this was used on 8-bit color displays, as it would add a "dithering" step.
Scalable fonts just add a step in the generation of the characters, which can then be put in cache and only hurt performance the first time they are generated. And some scalable formats included pre-generated bitmaps for the common sizes. Windows would happily return a font of this already generated sizes, instead of generating a new one, if the size we wanted was close enough.
Anyway, just to point out one of the many things we now take for granted that are possible because we have the CPU power, and the memory, for it.
Constant UI responsiveness Posted Mar 1, 2009 5:56 UTC (Sun) by eru (subscriber, #2753) [Link] Anti-aliased text would not really be needed much if the Linux font scaling would work better (like as well as in Windows 3.1). The big obstacle here is of course the infamous software patent that prevents FreeType from working as well as it could. Another is the quality of free fonts, until very recently.In the past, I found the display looking much better for me, if I recompiled FreeType with the "illegal" bits of code enabled, and then turned antialiasing off. Without this the letters would be irritatingly fuzzy. Lately I have not bothered, mainly because larger display resolutions make the antialiasing fuzz less offensive.
Constant UI responsiveness Posted Feb 27, 2009 10:40 UTC (Fri) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
Is there a way to disable Anti-aliased fonts completely?
Constant UI responsiveness Posted Feb 27, 2009 23:19 UTC (Fri) by nix (subscriber, #2304) [Link]
Sure. In .fonts.conf:
<match target="font">
(And anyone who thinks this is a sane way to expose configuration state to
Constant UI responsiveness Posted Apr 7, 2013 12:24 UTC (Sun) by hummassa (subscriber, #307) [Link]
In my KDE "fonts" control panel, there is a "turn off antialias altogether" item.
Constant UI responsiveness Posted Feb 27, 2009 10:50 UTC (Fri) by epa (subscriber, #39769) [Link]
The Archimedes had anti-aliased, hinted outline fonts in 1989, and it was fast enough running on an 8MHz ARM chip. (Although the anti-aliased fonts were not used for dialogue boxes and widgets, but only for the contents of documents.)
Constant UI responsiveness Posted Feb 27, 2009 12:02 UTC (Fri) by k3ninho (subscriber, #50375) [Link]
And in 1994 the Acorn RiscPC had all its UI text displayed from outline fonts on a 30 or 33 MHz Arm610.
Constant UI responsiveness Posted Feb 27, 2009 13:18 UTC (Fri) by nlucas (subscriber, #33793) [Link]
Far from being an expert on the subject, but I would not be surprised if the RISC instruction set was the reason they could do it. After all they don't need SSE2/SSE3 instructions on RISC CPUs.
MMX instructions appeared on the Pentium Pro (don't remember the model) and on Pentiums at 166MHz (there was two versions, one without MMX). And MMX has that problem of sharing the floating point registers.
Multimedia instructions Posted Feb 27, 2009 16:21 UTC (Fri) by vonbrand (subscriber, #4458) [Link] The MMX and SSE stuff is about doing the same operation on several data in parallel (but working on small inputs, i.e., integers 8 bits wide). Some RISCy architectures have their own set of "multimedia" instructions.
Multimedia instructions Posted Feb 28, 2009 9:29 UTC (Sat) by nlucas (subscriber, #33793) [Link]
Sure, but alpha blending is just that.
By the nature of the RISC architecture, a lot of simple vector operations coded by hand would always outperform the same thing on earlier x86 CPUs, like the first Pentium.
I suppose there are more complex multimedia cases where it makes sense to have dedicated instructions equivalent to SSE on RISC machines.
Constant UI responsiveness Posted Feb 27, 2009 17:08 UTC (Fri) by drag (subscriber, #31333) [Link]
The reason they were able to do it was because they were dealing with limited color range and low resolution displays. It's not like they had much computing power left over to drive a Office suite or do any other form of multitasking.
That's all.
Try making that old Risc machine drive a modern LCD display with Alpha blending and see how far you get.
Constant UI responsiveness Posted Feb 27, 2009 12:05 UTC (Fri) by nix (subscriber, #2304) [Link]
I did a pile of benchmarking of font scrolling performance on the latest X server (now released as 1.6.0).
With the EXA glyph cache patch applied, AA and non-AA client-side fonts are nearly equivalent in performance, but there *is* a little CPU consumption from the X server which wasn't visible before, and peak scrolling speed (on my 1650x1050 widescreen, 1250MHz Athlon, Radeon 9250 AGP) is about half that of core fonts (where the fonts spray past in an utterly unreadable blur with no CPU consumption to speak of). Antialiased font rendering is actually about 5% *faster* than non-AA rendering, so I suspect the overhead of the actual antialiasing is drowned by other overheads (or perhaps it's just that antialiased rendering, as the common case, has been optimized more).
However, the difference between an utterly unreadable blur and a nearly unreadable blur isn't very significant to me: it still scrolls text off the top of the screen in a tiny fraction of a second.
(Without the EXA glyph cache, non-AA text in some cases can be hugely *slower* to render than AA text, and in both cases I was seeing >20s to scroll the screen up by a single line. But that's not AA overhead: that's transfers from VRAM, which are always going to be slow as treacle.)
Constant UI responsiveness Posted Feb 28, 2009 10:15 UTC (Sat) by nlucas (subscriber, #33793) [Link]
I'm using those mini-PC boards, like the VIA mini-ATX boards (and others, like the Geode based) to boot into a vesafb system for POS (Point of Sale) software.
The application uses FreeType to display anti-aliased text, but without any special optimization techniques other than brute caching and double-buffering. It works well, but can't afford to do much more without more complex optimization techniques (and then the best way would probably be to start using X).
The target machines range from Geodes with the power equivalent of a Pentium MMX@266MHz to modern Celerons @2GHz, so it's bearable enough on the Geode and instant on the Celeron.
I also can't afford to optimize the code for a specific machine, so it's just compiled with generic optimizations.
This POS machines are not always well tested. They are made to be compact and sometimes they don't have enough cooling space. For eye candy we have a screen-saver using alpha-blending to show a flashlight passing on the screen. Some lower end machines lock solid because they heat too much, so we limit that screen-saver to no more than a 5-minutes run.
|
|||||||||||||