User: Password:
Subscribe / Log in / New account

CrunchBang Linux 8.10

CrunchBang Linux 8.10

Posted Feb 27, 2009 3:27 UTC (Fri) by proski (subscriber, #104)
In reply to: CrunchBang Linux 8.10 by k8to
Parent article: CrunchBang Linux 8.10

Perhaps users have become less tolerant to slow computers.

(Log in to post comments)

Constant UI responsiveness

Posted Feb 27, 2009 4:42 UTC (Fri) by eru (subscriber, #2753) [Link]

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.

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 (subscriber, #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 (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">
<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*.)

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 (guest, #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.

CrunchBang Linux 8.10

Posted Feb 27, 2009 7:09 UTC (Fri) by k8to (subscriber, #15413) [Link]

The computer was perfectly responsive, when it wasn't swapping.
It only swapped when running mozilla, all other programs were fine.

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?

CrunchBang Linux 8.10

Posted Feb 27, 2009 11:47 UTC (Fri) by jamesh (guest, #1159) [Link]

While a lot of that is due to size increases in userspace, there are overheads in managing the extra resources found in a system today (e.g. it takes more memory to manage 2GB of memory than it does to manage 64MB). Also, if you're using a 64-bit kernel certain structures now take up more memory too.

CrunchBang Linux 8.10

Posted Feb 27, 2009 12:07 UTC (Fri) by alankila (guest, #47141) [Link]

It's pretty much everyone. I think hal is relatively innocuous, and udev is very cheap, too. No, the problem appears to be with the GUI programs that make for instance the default GNOME desktop.

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...

CrunchBang Linux 8.10

Posted Feb 27, 2009 12:35 UTC (Fri) by alankila (guest, #47141) [Link]

Hmm. This bug may be about it: Pango might be culprit for wasting 6 MB per app:

CrunchBang Linux 8.10

Posted Feb 27, 2009 15:32 UTC (Fri) by biged (guest, #50106) [Link]

interesting - the problem as reported, and patched, reduced system footprint from 200M to 130M - very significant.

CrunchBang Linux 8.10

Posted Feb 27, 2009 14:57 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

From top output:

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?

CrunchBang Linux 8.10

Posted Feb 27, 2009 15:17 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

For comparision, the editor "joe" (with just one file, but it was twice as large as the total length of the three in gedit) had a resident size of 2M.

CrunchBang Linux 8.10

Posted Feb 27, 2009 16:14 UTC (Fri) by nix (subscriber, #2304) [Link]

Much of xorg's RSS is going to be things like mmap()ed video memory: not relevant here.

CrunchBang Linux 8.10

Posted Feb 27, 2009 16:16 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

Ah, I was wondering...

CrunchBang Linux 8.10

Posted Feb 27, 2009 23:22 UTC (Fri) by jwb (guest, #15467) [Link]

Part of the problem is the explosion of storage-to-memory ratio. 15 years ago I had a computer with 20 times more storage than memory. Now I have a thousand times more storage than memory. It takes extra memory just to manage a filesystem that scales up to that size.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds