In the MSDOS days the numbered function keys were very popular as the way to do anything other than typing text to the computer. Ctrl and alt were often used to make there be 4 times as many function keys, but were not used with letters for anything.
For a lot of people the only use of Alt was to type foreign letters (you held down Alt and typed the octal into the numeric keypad, and lots of people memorized all the ibm character set in this way).
The one use for Ctrl+letters was to control the few programs that used DOS to read the keyboards (because these programs could not see any of the function keys). Ctrl+P was a DOS command.com standard to execute a print-screen function. Supposedly MSDOS needed this, while PCDOS could use the BIOS call and get the PrtSc key.
When the Mac came out a lot of DOS programs copied it by using the Alt key, ie Alt+S to save, etc. NOT THE CTRL KEY though there seems to be a huge number of MicroSoft defenders who claim otherwise. Look at a contemporary Mac and PC keyboard and compare the locations of the "apple" and "Alt" keys and you will see why the Alt key was chosen.
It is not clear why MicroSoft switched things to the Ctrl key. One is that IBM's CDE designs had the Alt key doing strange things to navigate menubars. Also some foreign keyboards used the Alt to type foreign letters, and that Alt+numeric keypad stuff was still in lots of use. They probably also confused menu bar items with local actions used by widgets, in fact we would be much better if Ctrl+x cut text and Alt+x cut the objects the program works with, right now you cannot put a text field into the main window, or selecting objects requires the focus to navigate to the selection area, both of which greatly hinder GUI design.
In any case the use of Ctrl is more from windows 93 or so. It broke a lot of ported DOS applications, and made it hard to migrate between Mac and PC, it also made it impossible to do Emacs style ctrl keys in text fields, which made typing and editing text way slower. It also caused all the "Linux apps are inconsistent" because in fact Windows was inconsistent with general practice at that time and Linux tries to port apps from both Windows and Mac.
Sorry I used the wrong term. When I said "dithering" I meant "error diffusion". I have gotten into the bad habit of calling it "dithering".
Patterned dithering (as used by Display PostScript and Windows in 8-bit mode) is quite useless for a quality version of anything.
But error-diffusion is extremely good for movies. I feel it is an idealized minimal noise that can be added (you can add more noise to make the image look even "better" but error diffusion is a minimum value). See my sketch at Siggraph if you are interested in the methods I use (blatent plug).
Dithering will get rid of banding completely, even on 8-bit screens. You must also reset the gamma to standards (none of the Mac/SGI 1.8 type gammas, put it back to the darker 1.0 that a cheapo PC does), because then the colors are more evenly distributed in perceptual space.
Without dithering you would probably need 16 bits or more to not see banding in a gradual gray shade. Another solution would be to have the DA converter artifically add noise, which would hide banding enought to probably allow 12 bits to work. But software dithering would easily be much better.
All this is interesting but everybody seems to be ignoring the fact that Blender also made a version for Windows users. In fact they marketed the Windows version a lot more, and when I last saw a demonstration (at Siggraph) the Windows version was a later revision than the OS9 or Linux versions indicating that development was done there first.
You may be joking, but "free beer" is derived from a sentence RMS (or Gnu, or somebody) said to differentiate two possible meanings of the word "free": "Free as in 'free beer' or free as in 'free speech'".
The idea is that when you hear the term "free speech" you usually think of the freedom of the speaker, not that the speech is available for no cost. And when you think of "free beer" you usually think of the beer being available at no cost.
I feel sorry for you if you have never seen free beer. Don't you have any friends who party?
There are two requirements that everybody here thinks MicroSoft is going to ignore and that is really the reason we are scared of this:
1. It is vital that it be easy for a program to get *all* the data about a file (the metadata and data) into a single block of bytes. This is because a huge amount of software is concerned with transferring of file's contents from point a to b and needing to force the data through unknown communication mechanisms, most of which involve imbedding the file into another file. Most people here think MicroSoft is going to put us back to the 1960's where "pip" was a huge and complex and bug-loaded mess, and abandon the Unix "cp" which is tiny.
2. It is also vital that *every single piece of data* be accessable by a single string name passed to the *SAME* call (ie "open"), followed by some seeking and reading (the less the better), and the data is retrievable. Both Unix and Windows fall down badly here (see Plan9 and the Linux/proc for examples of solutions) but it is strongly believed that MicroSoft's programmers are too stupid to do this correctly.
One reason a lot of people say "imbed the data in the file" is to solve #1. However this makes #2 difficult. It is also impossible for file formats that don't have the ability to store an arbitrary-sized comment. But conversly (unlike what I think MicroSoft wants to do) we should not *disallow* putting the data in the file, this would instead be a last-stage fallback. It is also the only way to store this data on legacy file systems so it is still readable by older systems.
My proposal requires changing the file system so that very small files are FAST and every file is a directory. I believe ReiserFS has both of these requirements.
1. Pieces of metadata is accessed by opening and reading or writing "filename/metadataname". Attempts to write badly-formatted metadata may fail on close() and leave the data unchanged.
2. Every single piece of information about the file except it's name is metadata. This includes the date, owner, group, permission bits, ACL. (obviously you need the correct permission to change any metadata, and some hacks are needed to prevent "give this file to somebody else" security risks).
3. A "block" of data including all metadata is accessed by opening and reading or writing "filename/". Seeks are not allowed. The resulting data would be somewhat like tar. This should return the entire contents of directory trees as one block.
4. Add some calls to libc to use this to atomically copy or move any name to any other, preserving metadata and recursively copying subdirectories (like cp -a).
5. Provide a library that constructs missing metadata by examining the file itself for comments, examining the filename, etc. Programs may call this library instead of reading the metadata directly.
Linux has the same problem. My machine grinds like crazy at 2am trying to update "locate". I never use locate (when I've tried it never returns any useful data) but I don't have any idea what I do to stop this from happening (I've looked in the crontabs and whatever for what is doing this but I can't find how to turn this off).
It is depressing that Linux is copying some (or all) of the stupid things in Windows.
The bothersome part about this is that apparently the only reason for "window cloning" is to immediately change the new window to a different page. You didn't mention the one thing that it does that can't be done with middle-mouse, which is let you scroll the same document to two different places at the same time.
Sort of like fork and exec, so for that reason I would think this is a more Unix way of doing it while the way Mozilla works is more windows (where you cannot fork).
Anyway, it might make even more sense to get middle-mouse click to work everywhere to create a new window. It should work when form buttons are hit and if you use it to pick an item off the history or forward menu, or even clicking on the tabs.
Berlin's design is the exact opposite, and there are good arguments for doing it this way. At least it is consistent in that *everything* is on the same side. NeWS was also like this. In NeWS, even on slower hardware, the fact that all widgets could synchronize with the moving and resizing of the window made performace *much* better than X.
The current X design is to have all the widgets on the client side except for this one special widget, the "window". That seems wrong to me, everything should be together.
Personally though I think everything should be on the client side. The reason is that any interface to widgets will freeze us into present-day design. You can think the Berlin interface is really cool and customizable, but it probably locks in ideas like "scrollbar" and "text editing field" and "menu" that may be considered archaic in 10 years. I think that if X had done this approach we would all be using Athena widgets in lovely black&white and trying to defend why you need to use the middle mouse button to move the scrollbar, and Linux on the desktop would be a total joke. I don't want to see this happen, which is why I don't think Berlin is the right solution.
That's because those programs are doing exactly what I propose. Turning off the window borders pretty much reduces the window manager to the role of "task manager". (using override-redirect, as others have said, does not work, as the window manager and thus the "taskbar" do not see the app at all).
This may be a way to evolve X into what I propose. It needs more appliations to do this so that standards are agreed on, and there needs to be an interface so a "task" can announce itself without having to create a (mapped) window.
The delays are due to the seperate window manager and the rather kludgy communication between the program, X server, and window manager.
Everybody here had better learn to admit this is a problem.
The solution should also be looked at, and it is a killer: get rid of the "window manager". Most people seem to think this means that the window manager must be built into X, like Windows. But that only eliminates 1/2 the slow communication, and has the unfortunate effect of completely freezing window management design, which is a problem Windows is having relative to Linux right now (read the above comments!)
What I mean is "window managment" (meaning the positioning, decoration, moving, resizing, etc) of windows, should be part of the toolkit. The window border is no different than a button or anything elss. All sane people (there are some exceptions here) know that the drawing of the button should be up to the appliation or the shared libraries it decides to load, so why not the window borders?
But all the window borders will look different! Yes, they will. That is because it is impossible to have "consistency" and at the same time have "innovation". Think about it. And all those people who worry about "consistent user interface" should go and talk to some real users and they will find out that "consistency" is way overrated. Why aren't games "consistent"? Because they want to advance the state of the art. And I'm sure somebody will say "hey I was confused by the inconsistent Linux GUI", but think about it: what you really were confused by was two different interfaces, one a "stupid" design and one a (possibly) "smart" design. You were not confused by the inconsistency, you were confused because one of the interfaces was stupid. Also, look at the toolkits, with no requirements that they share code, they are pretty damn consistent, because they copy the working ideas from each other! If X had envorced "consistency" we would all be using the Athena widget set right now and trying to brag to Windows users that we can swap white and black in our preferences.
When we get rid of the window manager you will probably see some real innovation, like windows without borders (you move/raise them by grabbing any inactive area), and intellegent window stacking and ordering by programs that know exactly what window is important right now.
There will have to be a "task manager" (go ahead and take the Windows term, it won't bite). It would be like the "panel" in Gnome and programs would indicate they are running and respond to messages saying "appear" and "disappear" (or they can ignore the messages just to cause trouble, but it should be allowed).
You don't seem to know the full horrors of what Windows DLL's can do. If you have to program it for awhile you will learn.
I would very much expect a crashed IE to leave the system unusable if it really is "part of the os" like MicroSoft claims. Because of the way the DLL's work it would be like a program on X being able to write over the structures in the X server with random garbage before crashing (this is possible with some of the dubuous hardware acceleration hacks being done). You can be sure that that X server is going down soon!
Huh? I doubt the chop shop will care or reduce their pay because a window is broken. Glass is one of the few things that chop shops can't sell because insurance usually covers glass 100% and thus people have no incentive to find cheaper glass.
We aren't trying to get laws passed that say it is illegal to make a compiler that compiles GNU code without posting it to the net. We are not passing laws that say it is illegal to copy data.
If somebody copies GNU code and gets caught then the law applies. The same thing should be true for movies and music. They are perfectly in their rights to shut down web sites and arrest people who are copying their copyrighted works and distributing them for free. They are not in their rights in trying to control how I use my own copy and computer.
#2: it is not "use" of the code that requires them to release the new version, it is *distribution* of the code. You can take any GPL program and write your own in-house variation with your own proprietery additions, and NEVER release the code, as long as the resulting program is used in-house.
Most likely they can "use the product without paying" by copying the binary.
You seem to have missed what the point of the source code is. It is not to make the program have zero cost, there are much more effective ways to do that.
Yes, this is exactly what is missing in all the antialiasing solutions so far. Perhaps Xft can do this correctly and beat everybody! Here is my suggestion:
The brightness of a byte on the screen (after the byte is scaled to the range 0-1) is best described by the sRGB standard:
V = B However it can also be simulated rather accurately as B*B, if that is useful for fast implementation.
Using the B*B approximation: If C is the coverage of a pixel in a letter then the output color of drawing a pixel of color F against a background of color B is
sqrt((F*F-B*B)*C+B*B).
A more complex formula can be made by using sRGB instead of B*B. This may be worth it if a lookup table is used.
I see a few ways to accomplish this with reasonable speed:
1. Some trick with shifts and masking could be done to simulate the above function in integer math.
2. There are 256 values for F and 256 values for B. There are also some number of values for C, I think only 17 for the current antialiasing algorithim. This results in a lookup table of 1088K.
3. Some combination of integer math and a smaller lookup table.
4. Any of these tricks could be done in hardware, though that likely means MicroSoft did it first.
Re: #5, the need for fallback Xlib font code: actually the Xft extension is the first example I have ever seen in X where an extension is written correctly, it contains the fallback code! If your program uses it, it will still work if connected to an X server, because Xft will recognize this, and emulate itself as well as possible on it (it does a good job, too, the quality is equal to fltk where I worked quite a lot on selecting the proper Xlib fonts).
I want to congratulate Keith on actually doing this right. But one of the big problems with X is that no other "extension" has ever done this, forcing every programmer who wants to use the extension to "detect" it and have fallback code. This has been true for 15 years, back to the shared memory extension. This is a very bad design because it strongly discourages uses of the extensions.
Your other comments have merit, though I think client-side rendering is probably necessary for accurate word processors. But they really should rewrite Xlib and replace the font calls with something that calls Xft so that every program gets antialiased fonts. It is shameful that they have not done this, it means that even if we have the most beautiful AA in the world half the programs on Linux will still look ancient.
The left image had the (apparently broken) "hinting" turned on, which mangled the sizes of the characters. But both then rendered the resulting characters with the same anti-aliasing algorithim.
Although "Clear Type" as described by MicroSoft is useless on CRT's, there sure are a lot of reports of people here saying they "clicked ClearType on and the display is better". They are either delusional or the "Clear Type checkbox" is also changing the basic anti-aliasing algorithim.
Certainly the XP machines I have seen in stores (which are probably at the default settings) have nice anti-aliasing on the fonts in the dialog boxes. I would consider it the equal of what I have seen on OSX and from Xft when it works. I don't think we will see better until hardware is added to properly composite the a-a images in gamma corrected space.
So I suspect people are clicking the checkmark, Windows is figuring out they don't have an LCD and not actually changing things, and the people are fooling themselves into thinking the display is better when in fact it is the same.
Correct anti-aliasing like it appears they are doing now allows even the tiny fonts to be antialiased and readable, and it looks like they enable it all the time now. "font smoothing" appeared to be a hack that recognized patterns of pixels, much like the old Macintosh "smooth printing" did.
The algorithims being used by Xft and OS/X are the same as these new correct anti-aliasing used in XP, and thus both have tried to antialias all fonts. Although there are bugs in Xft, when it works it looks to me that all fonts can be better with antialiasing.
I did try doing shifts and or into a word, instead of the multiply and the result was slower, this was on both MIPS and Pentium. I'm sure the compilers could have done better, but it is possible that the only better thing would have been to recognize the equivalence to the multiply and do that.
Slashdot Mirror
For a lot of people the only use of Alt was to type foreign letters (you held down Alt and typed the octal into the numeric keypad, and lots of people memorized all the ibm character set in this way).
The one use for Ctrl+letters was to control the few programs that used DOS to read the keyboards (because these programs could not see any of the function keys). Ctrl+P was a DOS command.com standard to execute a print-screen function. Supposedly MSDOS needed this, while PCDOS could use the BIOS call and get the PrtSc key.
When the Mac came out a lot of DOS programs copied it by using the Alt key, ie Alt+S to save, etc. NOT THE CTRL KEY though there seems to be a huge number of MicroSoft defenders who claim otherwise. Look at a contemporary Mac and PC keyboard and compare the locations of the "apple" and "Alt" keys and you will see why the Alt key was chosen.
It is not clear why MicroSoft switched things to the Ctrl key. One is that IBM's CDE designs had the Alt key doing strange things to navigate menubars. Also some foreign keyboards used the Alt to type foreign letters, and that Alt+numeric keypad stuff was still in lots of use. They probably also confused menu bar items with local actions used by widgets, in fact we would be much better if Ctrl+x cut text and Alt+x cut the objects the program works with, right now you cannot put a text field into the main window, or selecting objects requires the focus to navigate to the selection area, both of which greatly hinder GUI design.
In any case the use of Ctrl is more from windows 93 or so. It broke a lot of ported DOS applications, and made it hard to migrate between Mac and PC, it also made it impossible to do Emacs style ctrl keys in text fields, which made typing and editing text way slower. It also caused all the "Linux apps are inconsistent" because in fact Windows was inconsistent with general practice at that time and Linux tries to port apps from both Windows and Mac.
Patterned dithering (as used by Display PostScript and Windows in 8-bit mode) is quite useless for a quality version of anything.
But error-diffusion is extremely good for movies. I feel it is an idealized minimal noise that can be added (you can add more noise to make the image look even "better" but error diffusion is a minimum value). See my sketch at Siggraph if you are interested in the methods I use (blatent plug).
Without dithering you would probably need 16 bits or more to not see banding in a gradual gray shade. Another solution would be to have the DA converter artifically add noise, which would hide banding enought to probably allow 12 bits to work. But software dithering would easily be much better.
If they lose their advertisers but have subscribers, they can easily keep their subscribers by discontinuing the free version.
All this is interesting but everybody seems to be ignoring the fact that Blender also made a version for Windows users. In fact they marketed the Windows version a lot more, and when I last saw a demonstration (at Siggraph) the Windows version was a later revision than the OS9 or Linux versions indicating that development was done there first.
The idea is that when you hear the term "free speech" you usually think of the freedom of the speaker, not that the speech is available for no cost. And when you think of "free beer" you usually think of the beer being available at no cost.
I feel sorry for you if you have never seen free beer. Don't you have any friends who party?
1. It is vital that it be easy for a program to get *all* the data about a file (the metadata and data) into a single block of bytes. This is because a huge amount of software is concerned with transferring of file's contents from point a to b and needing to force the data through unknown communication mechanisms, most of which involve imbedding the file into another file. Most people here think MicroSoft is going to put us back to the 1960's where "pip" was a huge and complex and bug-loaded mess, and abandon the Unix "cp" which is tiny.
2. It is also vital that *every single piece of data* be accessable by a single string name passed to the *SAME* call (ie "open"), followed by some seeking and reading (the less the better), and the data is retrievable. Both Unix and Windows fall down badly here (see Plan9 and the Linux /proc for examples of solutions) but it is strongly believed that MicroSoft's programmers are too stupid to do this correctly.
One reason a lot of people say "imbed the data in the file" is to solve #1. However this makes #2 difficult. It is also impossible for file formats that don't have the ability to store an arbitrary-sized comment. But conversly (unlike what I think MicroSoft wants to do) we should not *disallow* putting the data in the file, this would instead be a last-stage fallback. It is also the only way to store this data on legacy file systems so it is still readable by older systems.
My proposal requires changing the file system so that very small files are FAST and every file is a directory. I believe ReiserFS has both of these requirements.
1. Pieces of metadata is accessed by opening and reading or writing "filename/metadataname". Attempts to write badly-formatted metadata may fail on close() and leave the data unchanged.
2. Every single piece of information about the file except it's name is metadata. This includes the date, owner, group, permission bits, ACL. (obviously you need the correct permission to change any metadata, and some hacks are needed to prevent "give this file to somebody else" security risks).
3. A "block" of data including all metadata is accessed by opening and reading or writing "filename/". Seeks are not allowed. The resulting data would be somewhat like tar. This should return the entire contents of directory trees as one block.
4. Add some calls to libc to use this to atomically copy or move any name to any other, preserving metadata and recursively copying subdirectories (like cp -a).
5. Provide a library that constructs missing metadata by examining the file itself for comments, examining the filename, etc. Programs may call this library instead of reading the metadata directly.
It is depressing that Linux is copying some (or all) of the stupid things in Windows.
Sort of like fork and exec, so for that reason I would think this is a more Unix way of doing it while the way Mozilla works is more windows (where you cannot fork).
Anyway, it might make even more sense to get middle-mouse click to work everywhere to create a new window. It should work when form buttons are hit and if you use it to pick an item off the history or forward menu, or even clicking on the tabs.
The current X design is to have all the widgets on the client side except for this one special widget, the "window". That seems wrong to me, everything should be together.
Personally though I think everything should be on the client side. The reason is that any interface to widgets will freeze us into present-day design. You can think the Berlin interface is really cool and customizable, but it probably locks in ideas like "scrollbar" and "text editing field" and "menu" that may be considered archaic in 10 years. I think that if X had done this approach we would all be using Athena widgets in lovely black&white and trying to defend why you need to use the middle mouse button to move the scrollbar, and Linux on the desktop would be a total joke. I don't want to see this happen, which is why I don't think Berlin is the right solution.
This may be a way to evolve X into what I propose. It needs more appliations to do this so that standards are agreed on, and there needs to be an interface so a "task" can announce itself without having to create a (mapped) window.
Everybody here had better learn to admit this is a problem.
The solution should also be looked at, and it is a killer: get rid of the "window manager". Most people seem to think this means that the window manager must be built into X, like Windows. But that only eliminates 1/2 the slow communication, and has the unfortunate effect of completely freezing window management design, which is a problem Windows is having relative to Linux right now (read the above comments!)
What I mean is "window managment" (meaning the positioning, decoration, moving, resizing, etc) of windows, should be part of the toolkit. The window border is no different than a button or anything elss. All sane people (there are some exceptions here) know that the drawing of the button should be up to the appliation or the shared libraries it decides to load, so why not the window borders?
But all the window borders will look different! Yes, they will. That is because it is impossible to have "consistency" and at the same time have "innovation". Think about it. And all those people who worry about "consistent user interface" should go and talk to some real users and they will find out that "consistency" is way overrated. Why aren't games "consistent"? Because they want to advance the state of the art. And I'm sure somebody will say "hey I was confused by the inconsistent Linux GUI", but think about it: what you really were confused by was two different interfaces, one a "stupid" design and one a (possibly) "smart" design. You were not confused by the inconsistency, you were confused because one of the interfaces was stupid. Also, look at the toolkits, with no requirements that they share code, they are pretty damn consistent, because they copy the working ideas from each other! If X had envorced "consistency" we would all be using the Athena widget set right now and trying to brag to Windows users that we can swap white and black in our preferences.
When we get rid of the window manager you will probably see some real innovation, like windows without borders (you move/raise them by grabbing any inactive area), and intellegent window stacking and ordering by programs that know exactly what window is important right now.
There will have to be a "task manager" (go ahead and take the Windows term, it won't bite). It would be like the "panel" in Gnome and programs would indicate they are running and respond to messages saying "appear" and "disappear" (or they can ignore the messages just to cause trouble, but it should be allowed).
Ok enough ranting on Slashdot.
I would very much expect a crashed IE to leave the system unusable if it really is "part of the os" like MicroSoft claims. Because of the way the DLL's work it would be like a program on X being able to write over the structures in the X server with random garbage before crashing (this is possible with some of the dubuous hardware acceleration hacks being done). You can be sure that that X server is going down soon!
Huh? I doubt the chop shop will care or reduce their pay because a window is broken. Glass is one of the few things that chop shops can't sell because insurance usually covers glass 100% and thus people have no incentive to find cheaper glass.
If somebody copies GNU code and gets caught then the law applies. The same thing should be true for movies and music. They are perfectly in their rights to shut down web sites and arrest people who are copying their copyrighted works and distributing them for free. They are not in their rights in trying to control how I use my own copy and computer.
#2: it is not "use" of the code that requires them to release the new version, it is *distribution* of the code. You can take any GPL program and write your own in-house variation with your own proprietery additions, and NEVER release the code, as long as the resulting program is used in-house.
You seem to have missed what the point of the source code is. It is not to make the program have zero cost, there are much more effective ways to do that.
V = B < .04045 ? v/12.92 : pow((v+.055)/1.055, 2.4)
The brightness of a byte on the screen (after the byte is scaled to the range 0-1) is best described by the sRGB standard:
V = B However it can also be simulated rather accurately as B*B, if that is useful for fast implementation.
Using the B*B approximation: If C is the coverage of a pixel in a letter then the output color of drawing a pixel of color F against a background of color B is
sqrt((F*F-B*B)*C+B*B).
A more complex formula can be made by using sRGB instead of B*B. This may be worth it if a lookup table is used.
I see a few ways to accomplish this with reasonable speed:
1. Some trick with shifts and masking could be done to simulate the above function in integer math.
2. There are 256 values for F and 256 values for B. There are also some number of values for C, I think only 17 for the current antialiasing algorithim. This results in a lookup table of 1088K.
3. Some combination of integer math and a smaller lookup table.
4. Any of these tricks could be done in hardware, though that likely means MicroSoft did it first.
I want to congratulate Keith on actually doing this right. But one of the big problems with X is that no other "extension" has ever done this, forcing every programmer who wants to use the extension to "detect" it and have fallback code. This has been true for 15 years, back to the shared memory extension. This is a very bad design because it strongly discourages uses of the extensions.
Your other comments have merit, though I think client-side rendering is probably necessary for accurate word processors. But they really should rewrite Xlib and replace the font calls with something that calls Xft so that every program gets antialiased fonts. It is shameful that they have not done this, it means that even if we have the most beautiful AA in the world half the programs on Linux will still look ancient.
The left image had the (apparently broken) "hinting" turned on, which mangled the sizes of the characters. But both then rendered the resulting characters with the same anti-aliasing algorithim.
Certainly the XP machines I have seen in stores (which are probably at the default settings) have nice anti-aliasing on the fonts in the dialog boxes. I would consider it the equal of what I have seen on OSX and from Xft when it works. I don't think we will see better until hardware is added to properly composite the a-a images in gamma corrected space.
So I suspect people are clicking the checkmark, Windows is figuring out they don't have an LCD and not actually changing things, and the people are fooling themselves into thinking the display is better when in fact it is the same.
Correct anti-aliasing like it appears they are doing now allows even the tiny fonts to be antialiased and readable, and it looks like they enable it all the time now. "font smoothing" appeared to be a hack that recognized patterns of pixels, much like the old Macintosh "smooth printing" did.
The algorithims being used by Xft and OS/X are the same as these new correct anti-aliasing used in XP, and thus both have tried to antialias all fonts. Although there are bugs in Xft, when it works it looks to me that all fonts can be better with antialiasing.
I think you are right. I may be confusing this with code used by the compilers to compare "far" pointers for equality.
I did try doing shifts and or into a word, instead of the multiply and the result was slower, this was on both MIPS and Pentium. I'm sure the compilers could have done better, but it is possible that the only better thing would have been to recognize the equivalence to the multiply and do that.