Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Perhaps users have become less tolerant to slow computers.
Constant UI responsiveness
Posted Feb 27, 2009 4:42 UTC (Fri) by eru (subscriber, #2753)
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.
Posted Feb 27, 2009 7:22 UTC (Fri) by nlucas (subscriber, #33793)
Posted Feb 27, 2009 8:14 UTC (Fri) by eru (subscriber, #2753)
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.
Posted Feb 27, 2009 9:03 UTC (Fri) by farnz (guest, #17727)
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.
Posted Feb 27, 2009 9:10 UTC (Fri) by nlucas (subscriber, #33793)
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.
Posted Mar 1, 2009 5:56 UTC (Sun) by eru (subscriber, #2753)
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.
Posted Feb 27, 2009 10:40 UTC (Fri) by firstname.lastname@example.org (guest, #38022)
Posted Feb 27, 2009 23:19 UTC (Fri) by nix (subscriber, #2304)
<edit name="antialias" mode="assign"><bool>false</bool></edit>
(And anyone who thinks this is a sane way to expose configuration state to
users should see a psychologist *fast*.)
Posted Apr 7, 2013 12:24 UTC (Sun) by hummassa (subscriber, #307)
Posted Feb 27, 2009 10:50 UTC (Fri) by epa (subscriber, #39769)
Posted Feb 27, 2009 12:02 UTC (Fri) by k3ninho (subscriber, #50375)
Posted Feb 27, 2009 13:18 UTC (Fri) by nlucas (subscriber, #33793)
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.
Posted Feb 27, 2009 16:21 UTC (Fri) by vonbrand (subscriber, #4458)
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.
Posted Feb 28, 2009 9:29 UTC (Sat) by nlucas (subscriber, #33793)
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.
Posted Feb 27, 2009 17:08 UTC (Fri) by drag (subscriber, #31333)
Try making that old Risc machine drive a modern LCD display with Alpha blending and see how far you get.
Posted Feb 27, 2009 12:05 UTC (Fri) by nix (subscriber, #2304)
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.)
Posted Feb 28, 2009 10:15 UTC (Sat) by nlucas (subscriber, #33793)
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.
CrunchBang Linux 8.10
Posted Feb 27, 2009 7:09 UTC (Fri) by k8to (subscriber, #15413)
I'm just wondering what the bloat statistics are that a "bare bones" system now uses around 120 megs, when back then (2002-ish), my system used around 30. I certainly understand that browsers are now required to be more complicated, and that desktop environments have gotten more .. featureful. But this includes neither. Is this the responsibility of hal? udev? Everyone?
Posted Feb 27, 2009 11:47 UTC (Fri) by jamesh (guest, #1159)
Posted Feb 27, 2009 12:07 UTC (Fri) by alankila (subscriber, #47141)
On my Ubuntu install, I can count about 5 GNOME programs that I could easily live without, that each use unique memory between 5 to 15 MB. (Whatever they are sharing might come for free, or with smaller cost, and it is difficult to estimate.)
For instance, a monster called update-notifier has 23 MB resident memory, of which only 10 MB is shared. I don't know what that program does that is worth at least 13 MB, given that most of the time it just lurks invisibly in the background.
mixer-applet2 that mostly shows a single volume icon has a 22M - 10M statistic giving 12 MB private memory use. fast-user-switching-applet is the same. Gnome power manager costs 8M (on a desktop system, too, where it's worthless). Hell, mere trash icon in panel costs 3 MB.
No matter how efficient you try to make any individual process, there's also the problem that a linux desktop today runs about 150 process, of which about full 50 come from kernel (and are probably cheap). The 100 userland processes necessary to service a single user each spend some resources for sure, but at least most of them use less than 1 MB of private RAM.
Funnily, the process that uses just above 1 MB of private RAM here happens to be hald, every other system process consumes less. And everything above that point is mostly gnome stuff...
Posted Feb 27, 2009 12:35 UTC (Fri) by alankila (subscriber, #47141)
Posted Feb 27, 2009 15:32 UTC (Fri) by biged (subscriber, #50106)
Posted Feb 27, 2009 14:57 UTC (Fri) by michaeljt (subscriber, #39183)
RES SHR COMMAND
220m 28m firefox
123m 14m Xorg
100m 21m pidgin
76m 26m thunderbird-bin
39m 16m gedit
34m 14m nautilus
32m 14m gnome-terminal
Need more be said?
Posted Feb 27, 2009 15:17 UTC (Fri) by michaeljt (subscriber, #39183)
Posted Feb 27, 2009 16:14 UTC (Fri) by nix (subscriber, #2304)
Posted Feb 27, 2009 16:16 UTC (Fri) by michaeljt (subscriber, #39183)
Posted Feb 27, 2009 23:22 UTC (Fri) by jwb (guest, #15467)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds