On X you are able to set the window to "no background color" (actually this is the default) and it does nothing except send the Expose event to the application.
This is actually much faster, and certainly simpler. It is faster because the area is only drawn once (it is extremely hard to make the program's redraw be able to assumme the area is already erased, since the same code must be used for incremental update when there is no damage, and I doubt Mozilla does this).
More importantly this reduces blinking. For Mozilla which must change the background color for each page, except for a single background color (gray, probably) it will blink to gray and then to the correct color for every page. Even if the color is fixed, or even if background pixmaps are used, it will still blink when a large image or table in a different color is drawn in that area.
Blinking is very annoying and is the primary reason X displays often look like crap when you move windows.
I very much believe this is the correct behavior. I would like to see X fixed so that resizing and mapping windows, and in fact everything except drawing commands from the programs does not alter pixels on the screen. This would vastly reduce the annoying flashing behavior.
The fact that Mozilla is so slow that you would prefer to see the solid gray (actually a very slow version of this "blink") is of course Mozilla's fault, but erasing windows is not the solution.
NO, he means he can "install" the damn plugin without being su by simply copying a file to a certain directory (making that directory have a reasonable name and be under $HOME is also nice).
It is insane that we have to edit files (or run any kind of "installation" program, no matter how friendly) to tell the systems the simple fact that a file exists.
Hint to Mozilla: can't find a plugin? Try the handy Unix functions "opendir" and "readdir".
Apple should put a divide-by-2 on the clock input. Magically the chip is twice as fast! You could even try a divide-by-4 but that may not be believed by the public.
Seriously, wasn't there a time when chip makers actually did this to make their chips look faster?
Actually I think it is pretty common that the same X clipboard is used both for the middle-click and the ^X,^C,^V.
For those who complain about the "inability to replace" with the middle mouse, I will have to point out (yet again) that the X behavior is exactly the same as the much-lauded "drag and drop" except you don't have to hold the damn mouse button down as you move to the drop site. If you don't believe me, please think about it more carefully... What you are actually complaining about is also a limitation of "drag and drop", which is even worse. At least X lets you rearrange the windows to locate the drop site!
I use Linux because I want a Unix environment, not for any idelogical reasons. I would probably be using MicroSoft's stuff today if they were not so gratuitously incompatable with Unix
MicroSoft threw out fixes in OS design made by K&R in 1970, such as raw files, simplified file naming with only one reserved character (/), the ability to name objects other than disk files with the same interface as files. Then they took this stuff containing errors that were fixed over THIRTY years ago and have the gall to call it "new technology".
I actually believe that if MicroSoft had shown some technical class, humility, and a bit of respect for standards, then Linux would be for hobbyists only, and me and many other computer professionals would happily use their closed-source systems. However they blew it with their own arrogant and ignorant behavior.
Yea, right. I always buy my alcohol from the local moonshiner, and I go out to drink at the illegal speakeasy. Gosh, they are doing great business competing with that legal taxed stuff, aren't they?
Last time I tried (and this was XFree83 3.something, not 4!) it gave me a scrolling list of monitor types. I even found my monitor last time, though earlier installs I had to pick "generic multisync monitor".
Last time I looked the amazingly user-friendly Windoze also presented an identical list, but when I tried to pick my monitor it insisted I insert a disk which I did not have (I then picked generic and it worked).
Good point, in fact both are against freedom of speech.
The ACLU is generally considered pretty left-wing, but is very consistent in supporting any free speech. I also think the Republican type of censorship is more dangerous as they seem more intent on destroying information, while the Democrats (and most Republicans) are more against various forms of expression.
Re: Democrats ("Freedom of speech, except for whatever we deem 'offensive'")
Huh? It's the Republicans that try to ban flag burning or talk about sex. The Democrats are the ones who take our money for government handout programs.
Maybe a point could be made that the Democrats and Republicans are so alike that the actual alternatives, such as Libertarians, can no longer even tell which is which!
People keep asking "what is the equivalent of Add/Remove program" and we keep saying "this complex command is the equivalent of add, this complex command is the equivalent of remove" Then somebody else says "well, we should all get together and replace those complex commands with simple commands".
This is all bogus. The only reason people ask "what is the equivalent of Add/Remove" is because Windoze has "add/remove". There is no reason for such low-level concepts to be visible to the user.
In my opinion "add" should be executed by clicking on that "run this kool new software" icon shown in your browser, and "remove" should be "stop using the software" (or perhaps you have to drag the icon that appeared on your home page to the trash to get rid of the way of rerunning it).
Why forcing the poor user has to know about "installing" a piece of software. They don't need such knowledge. All they want is "make the machine do this interesting thing". Just because MicroSoft does it does not mean it is user-friendly.
From a practical point, the way to do this is:
Get rid of over-reliance on dynamic libraries by static-linking the binaries to any libraries other than libc and Xlib that you know are on the machine. Or use object services so the program at run-time can complain and perhaps get from the net any missing services, rather than refusing to run with DLL error.
Make the programs work without any "configuration" files (by making them use default values when the files are missing and writing new files when the user saves a configuration).
Make the linkers insert simple binary files in as raw data, so we can imbed large quantities of data into a program without a stupid filter to turn them into C initializers.
You mean people edit those MicroSoft Word documents at the byte level? I didn't know that, I was always under the impression that they cheated with some program called "Word". Well, apparently such cheater programs are not allowed...
This actually sounds like an ok solution. A few problems, which may be annoying:
Can you point to some documentation for Xft?
Does it do any kind of sharing when a few dozen applications all try to draw the same font? Perhaps this is not necessary nowadays? However this seems to be the obvious reason to put the fonts in the server.
If the X server does not have the render extension, can Xft work at all (even producing very bad output) or does it just abort? Unfortunately I think you better do something about old X servers, otherwise all the applications will do their own kludge, or worse it may discourage use of Xft at all.
Is there a *SIMPLE* font-naming scheme. By "simple" I mean that if I say "Helvetica" I get a font, ALWAYS! It is far, far, far more important that I get a font, and it be the same one every time, than that it actually be the sans-serif font "helvetica". Any scheme where the font names are not user-friendly will make applications and toolkit make their own translation from user-friendly to system names, and they will probably be incompatable with each other. Notice that it is ok to also support "complex" names that specify fonts exactly, as long as simple names are accepted. Also, ALWAYS return a font, no matter what garbage name is thrown at you, you can report an error, but make the best guess anyway.
Can you do anything about UTF-8? It would help a lot if there was a way to render raw UTF-8 strings (and 16 bit unicode while you are at it), and all characters show up. Best answer is to have a 16/8x16 bitmap font containing the entire Unicode set, and any missing letter from a font pulls if from there (clip and center it, don't scale except by integers).
Please draw something, even a box, for every single code. I recommend small "^A" for the control characters.
Draw the MicroSoft "extension" characters for the range 0x80-0xA0. Don't pretend that this is not a standard. It is and there is nothing we can do about it.
Bullshit. The application does not have any way to know what the exact bitmap being drawn for a font is (other than drawing it and grabbing the screen). Thus the "bit accurate control" argument is wrong. When I draw a font with xlib I want to see the font as nice as possible. I probably make a few assumptions that it wont extend more than 2 pixels or so outside the bounding box but otherwise my programs (and everybody else's) do not rely on bit accuracy! (if you are really paranoid, the antialiasing can be turned off when xor mode is enabled).
The "can't allocate colors" argument is also bullshit. I do not expect antialiased fonts to work without a TrueColor visual anyway, so there is no colormap to worry about!
The Xlib interface is entirely designed to be the same level as the Windows GDI. There is a 1:1 correspondence between the calls in many cases! (Windows copied lots of it, you know). The fact is that X botched the way to specifiy the fonts, so any practical interface requires an enormous and inefficient toolkit that has to enumerate every font on the server to find the correct one (this needs serious fixing with a new font-selection interface). However once you have selected the font you can use the drawing code in Xlib quite easily, without any toolkit wrapper.
Just quit with the lame excuses, and admit that the internal code is such a horrid mess that nobody in 10 years or so has been able to change it to non-binary!
"Just the toolkits" means: NO! It does not work for existing programs.
I feel it is inexcusable that they did not hack the existing font mechanism to do antialiased fonts. I want to point out that the much derided MicroSoft managed to add antialiasing to their existing rendering system without requireing the use of new interfaces.
Yes, adding a new and nicer interface is necessary, but they should have made the old interface, which is what existing programs use, work as nice as possible. The fact is that we are not going to see antialiased fonts on the screen for a LONG time even now, because they did not do this.
I expect OSX will have the same "zero click installation" that Windows has: it will be already on the machine when the people buy it.
Installation is not a good measure of ease of use, it is just a significant (perhaps insurmoutable) hurdle that Linux has that Windows does not. If Linux came pre-installed on machines you can bet that "difficulty of installation" would be WAY down the list of problems, like it is for Windows.
It would be user-friendly if a system could be figured out where you download a package as a single file, double-click it (or some command line program) and it then untarred, compiled, installed (after asking for root password) and deleted the tarred stuff. This could go a long way to distributing software that works on many different machines or different libaries. It could also pop up a panel that let the user choose the features to enable in the compile, you could run it again to compile with different features.
I know it will take a time, but the time does not seem to be a problem. On Windoze people are willing to double-click something and wait forever for it to do things like download from web sites, so compilation time is not a problem.
Obviously this "installer" program is a complex pain to write and there would have to be a standard.
As for screenshots, I definately want to see them, they help a lot in figuring out just what a program does.
Okay, I think I'm beginning to figure out where we are misunderstanding each other.
I totally agree that proper anti-aliasing and other compositing operators must be done in linear space, where the numerical values are equal to the light intensity multiplied by a constant. In my own work I use floating point numbers for this. This is important, as the intensity resolution must be much smaller near zero than away from it, floating point naturally does this, while using integers or fixed point results in huge waste of resolution at the bright end while making huge noticable steps at the black end. All cgi rendering programs work this way, I am working on fixing compositing software to work this way as well.
However, when I take that floating point number and put it into an 8-bit display buffer, I fully expect to "gamma correct" it, rather than do something simple like rint(x*255). (cheap or old cgi rendering software like still does this, completly ruining the realism of the result).
I was under the impression that you were arguing that the circuitry (D/A converter and display device) should be designed such that the output intensity is a constant multiplied by the value stored in the display buffer. As you seem to have a lot of knowledge about this, I must assumme that you are well aware that this is a very inefficient way to use the 8 bits. Ideally those 8-bit numbers should be used in a formula like pow(B,(x/255)-1) to get the intensity displayed on the screen, to get the limited number of intensities as evenly distributed across the "perceptual" scale, which is approximately logarithmic.
Further confusion is that the default behavior of a CRT screen and a linear D/A converter happens to be very close to the ideal for human vision, the gamma curve just happens to be the right power value so that it can be scaled to closely fit the log curve of human vision over the 100:1 or so range of intensities a CRT can display. This was entirely coincidental as it was not a design decision when television was developed.
Because of this coincidence, a good way to improve the display of an 8-bit buffer is to do nothing to the bits before sending them to the screen, this of course conflicts with the assuption that doing something complicated would be better.
Although I think it is stamped out now, around 1990-1994 or so there was a lot of belief that something complicated had to be done between the 8 bits and the CRT, so that nothing complicated had to be done when converting the floating point linear value to 8 bits. This resulted in people trying to "linearize" the monitors, such as the 1.7 gamma still built into Macintoshes, and the SGI software that set the gamma up as high as 2.5, both of these result in horrible banding in the dark areas. People then tried to solve this problem by raising the number of bits, first to 12, and then to 16, trying to get rid of the black banding. Though the extra bits are nice, they are still using them very inefficiently, 16 bits linear just equals the quality of an 8-bit 2.0 gamma display (the step between the bottom two entries is equal), while those same 16 bits used with gamma could give you 256 times as many gray levels!
I have only seen consumer CCD cameras so you may be talking about the internal circuitry or professional equipment, but certainly by the time they output a jpeg image for your photo cd, they have gamma-corrected the image. If they had not done so the display on a home pc through a non-correcting image viewer would be extremely dark. I agree that the CCD itself produces linear response. Also even the first tube cameras required adjustment circuitry, because even though they produced a gamma response, it was a different gamma than the television screens, and the engineers decided (for obvious reasons) to put the expensive adjustment circuitry in the camera rather than in every tv set.
On the eye, I was talking about the reception range of an individual cell, or two adjacent cells, simultaneously, you report this range as 100:1, though I have heard more. You are right that the cells as well as the pupil adjust, I did not know that the cells adjustment is far greater than the pupil, that is pretty interesting. However for our purposes, since all the pixels on the screen are being examined simultaneously, the range of the CRT is approaching that of the eye. My own believe is that we need to get it up to 10000:1 or so before truly realistic scenes can be displayed, as the eye adjusting to look in dark areas is quite natural and we need to stimulate that somewhat to get a fully natural feel.
Why not add a feature when Javascript is turned off (or in a browser that does not understand Javascript at all) that looks for URL's in the Javascript and assummes that a click on that thing is a jump to that URL? This should not be hard and would make the WWW usable without Javascript.
That may be better than my idea because it would allow you to look at the auto-forward page.
My idea would be to have the from page deleted from the history so that going back goes back to the last page you looked at, and going forward again skips the auto-forward page.
If the auto-forward page is reached from a bookmark perhaps the program should offer to fix your bookmark?
Unrelated, but I have always wanted buttons on the page that say "home" or "back" to work in the history, perhaps by having the browser search up the history for a match to any url it jumps to, and act as though the user selected that item off the history.
You seem to be quoting a lot of material, I am guessing we seem to be misunderstanding each other somehow, as what I am trying to say is trivial basic knowledge of how the eye responds to light that anybody who has read so much on light must know. I am guessing we are misundestanding the terms "linear" and so on.
The linear/logarithmic/gamma curve I am talking about is a plot from "number put into the display buffer" (called x here, and normalized so 0.0 is the smallest number in the buffer, and 1.0 is the largest number), and the "intensity of light emmitted by the screen" (called y here, and normalized so that 1.0 is maximum the screen + d:a converters produce, and 0.0 is the minimum).
"Linear" in my terminolgy means y = x.
"Gamma" means y = pow(x,G)
"Logarithimic" means y = pow(B,x-1)
The display buffer can only store discreet values, the difference between them is Dx (1/255 for an 8-bit buffer). This will produce descreet steps in the output intensity, the size of these is (approximately) dy/dx * Dx.
My argument is that the best use of this display buffer and hardware is if the perceived steps in output intensity are about equal. This is the only way to minimize the noticability of the steps everywhere.
It is pretty well established that the perceived difference in intensity is a ratio or (y+Dy)/y-1 or Dy/y.
Setting Dy/y to a constant means that dy/dx/y = c or dy/dx = y*C. This is the derivative of a logarithmic curve, which is why I say that a logarithmic curve is the ideal way to map the values in a display buffer to display intensities.
CRT monitors naturally map the voltage level through a gamma curve to the screen intensity, this gamma exponent G is about 1.8. I also propose that this gamma curve, though not equal, is quite close to a logarithimic curve (try drawing both of them in the range 0-1), and certainly MUCH MUCH better than a straight line plotted by a linear function.
Mach banding:
My understanding of the term "Mach banding" is the perception of an "edge" caused by the eye and brain amplifying discontinuities in the first derivative of the intensity across the scene, event though the value is continuous. What I think we are talking about is a discontinuous value, or step in intensity. I have never heard the term "Mach banding" applied to this.
CCD's
Yes CCD's are linear, but you will find that the circuitly in all digital cameras forces that linear output through a lookup table to convert it to a nonlinear value. This is necessary for compatability with all existing binary data formats which are based on binary values that are passed through a gamma function before producing output intensities.
Logarithimic matching exponential
Of course these don't match outside the 0-1 range, but since the monitor is physically incapable of producing these intensities anyway, it does not matter! I know perfectly well that the eye has greater dynamic range than the monitor, though it is not as great as you say if you discount the ability of the iris to reduce/increase exposure, in fact it is only about 1000:1. Inside the 0-1 range I think you will find that the gamma curve matches the exponent much better than a straight line, it is at least curved in the right direction!
References:
Digital Video and HDTV: Pixels, Pictures, and Perception, published by John Wiley & Sons in July, 2000.
Also check Siggraph course notes for Charles Poyntons introduction to color science and color management. It was course # 21 in the New Orleans 2000 Siggraph, but he has done the same course every year for awhile now.
Yes the markup over materials for computer parts is huge (and many orders of magnitude huger for software), but I don't think it is for cars.
If it was for cars, you could buy a car that is a "pirated copy from a Chinese company that got the blueprints somehow". The fact is, this does not happen.
Although dynamic linking allows the user to modify the library, I can't see this being used too much. Most useful modifications add new interfaces to the library, but these won't be used because the application cannot be changed to call them. Other modifications are bug fixes, and I really would rather that the user be forced to tell somebody about the bug, so that there is more chance it will be fixed in more than their copy.
In my experience dynamic linking makes the programs much larger. Dynamic linking cannot win unless more than one program is using the library, and I think for many useful LGPL libraries this is not true. Don't forget that each incompatable version can be considered a different library. Also you can easily tell that a dynamically linked executable takes much more disk space than a stripped static linked executable for a library like mine, where the functions are numerous and fairly small, because the symbols are actually larger than the linked objects! (it is true that these symbols do not take memory when loaded in).
I have also found dynamic linking to be a real pain to support. More than half the makefile is to get around problems with making shared libraries. On Windoze we are forced to add horrible kludges and macros to get around stupidity in VC++ design. Conversely, on Unix we have no ability to share symbols between source files without also bloating the library with another public symbol, and I am forced to arrange the code in weird ways to make as many variables static as possible.
Both systems have the annoying fact that if my library calls another shared library, you need to link that other library, even if you don't link to any functions that use it, this forced us to split the library into a part that uses OpenGL and a part that does not, and also forces me to design it to not call libimage or any other possibly useful library. (I would prefer a shared library system where a call to a missing library produces a crash with "Symbol XYZABC not found")
I can assure you that retaining binary compatability is a huge pain and seriously damages our ability to improve this product. Every change that would break binary compatability is being pushed to version 2.0, even though some of them are trivial (replacing some shorts with ints for widget positions) and have been wanted for more than a year.
And dynamic linking does make it a pain to "install" a program. A lot of useful utilites should be able to be downloaded as a single executable, double-clicked by a user with no permission, and they should work! This means all shared libraries must be installed on the machine, and I'm sorry to say my library is not popular enough that anybody can assumme that!
I actually think dynamic libraries are a mistake, almost all the time. Everybody here laughs at Windoze "DLL hell" but seem to refuse to believe that we are creating the same mess, or worse, on Linux. Dynamic libraries should be reserved for common system interfaces (ie libc). A lot of stuff that is dynamic like OpenGL should be written as a "service" with header files full of macros that shove the correct bytes to the service, and static-linked code to open a socket to the service (and don't complain that sockets are slow, FIX THEM! Also try to design interfaces where return values are not needed all the time, like OpenGL, so that synchronization is not needed and batch transfers can be done).
Not a good argument. SGI was forced to abandon their GL interface because of insistance that they be compatable with X (GL is related to OpenGL but had calls for fonts, windows, and events, and arguably was better, and certainly easier to program, than X. Whole 2-D interfaces with buttons and text fields were written using GL, and were quite fast on 10 Mhz machines, which shows that powerful graphics primitives are NOT slow).
They also had to give up on NeWS, they were the biggest user of NeWS other than Sun, and in fact used it far better and cleanly merged GL into it.
I want to release my library fltk under the LGPL and I do not mind if people use my library to write commercial or closed software, since this ability will make my library more popular, and since the use of my library will make it easier to port to Linux or other platforms. I also know the regular GPL is valuable and release all appliations I write as GPL, but I want to use LGPL here.
The problem is that the exact words of the LGPL seem to require dynamic linking of my library, so that it can be "replaced by the user". This imho is unacceptable, since my library is not popular and thus must be provided with the appliacation. This requires the application to be "installed", which greatly reduces it's ease of use. Perhaps more important: it means a programmer cannot modify my library (releasing the code modifications) and use it in their closed program, since the shared library would conflict with other users of my library, this completely defeats one of the main advantages of Open Source, which is that you can change it!
I have taken to adding a disclaimer that says "static linking of my library is allowed, no matter what the LGPL says, and is in fact even encouraged". But I would like to know if there is any better way, or if the LGPL allows this.
I would prefer not to make my own license just because of this, since we have way too many licenses as is, but this worries me no end...
The cost of building a car is very close to the price it is sold for. It is in fact the exact opposite of the software industry!
In automobiles it is worth an entire engineer's yearly salary to figure out how to replace a 10-cent widget with a 5-cent one. This saving of 5 cents on a 15,000 dollar item is important because the margin is very small.
Yes there are huge armies of engineers designing the cars, but their cost is still pretty small compared to the materials, labor, shipping, sales commisions, advertising, etc. You have to take into account the enormous numbers of cars sold.
Slashdot Mirror
This is actually much faster, and certainly simpler. It is faster because the area is only drawn once (it is extremely hard to make the program's redraw be able to assumme the area is already erased, since the same code must be used for incremental update when there is no damage, and I doubt Mozilla does this).
More importantly this reduces blinking. For Mozilla which must change the background color for each page, except for a single background color (gray, probably) it will blink to gray and then to the correct color for every page. Even if the color is fixed, or even if background pixmaps are used, it will still blink when a large image or table in a different color is drawn in that area.
Blinking is very annoying and is the primary reason X displays often look like crap when you move windows.
I very much believe this is the correct behavior. I would like to see X fixed so that resizing and mapping windows, and in fact everything except drawing commands from the programs does not alter pixels on the screen. This would vastly reduce the annoying flashing behavior.
The fact that Mozilla is so slow that you would prefer to see the solid gray (actually a very slow version of this "blink") is of course Mozilla's fault, but erasing windows is not the solution.
It is insane that we have to edit files (or run any kind of "installation" program, no matter how friendly) to tell the systems the simple fact that a file exists.
Hint to Mozilla: can't find a plugin? Try the handy Unix functions "opendir" and "readdir".
Seriously, wasn't there a time when chip makers actually did this to make their chips look faster?
For those who complain about the "inability to replace" with the middle mouse, I will have to point out (yet again) that the X behavior is exactly the same as the much-lauded "drag and drop" except you don't have to hold the damn mouse button down as you move to the drop site. If you don't believe me, please think about it more carefully... What you are actually complaining about is also a limitation of "drag and drop", which is even worse. At least X lets you rearrange the windows to locate the drop site!
MicroSoft threw out fixes in OS design made by K&R in 1970, such as raw files, simplified file naming with only one reserved character (/), the ability to name objects other than disk files with the same interface as files. Then they took this stuff containing errors that were fixed over THIRTY years ago and have the gall to call it "new technology".
I actually believe that if MicroSoft had shown some technical class, humility, and a bit of respect for standards, then Linux would be for hobbyists only, and me and many other computer professionals would happily use their closed-source systems. However they blew it with their own arrogant and ignorant behavior.
Yea, right. I always buy my alcohol from the local moonshiner, and I go out to drink at the illegal speakeasy. Gosh, they are doing great business competing with that legal taxed stuff, aren't they?
Last time I looked the amazingly user-friendly Windoze also presented an identical list, but when I tried to pick my monitor it insisted I insert a disk which I did not have (I then picked generic and it worked).
The ACLU is generally considered pretty left-wing, but is very consistent in supporting any free speech. I also think the Republican type of censorship is more dangerous as they seem more intent on destroying information, while the Democrats (and most Republicans) are more against various forms of expression.
Huh? It's the Republicans that try to ban flag burning or talk about sex. The Democrats are the ones who take our money for government handout programs.
Maybe a point could be made that the Democrats and Republicans are so alike that the actual alternatives, such as Libertarians, can no longer even tell which is which!
This is all bogus. The only reason people ask "what is the equivalent of Add/Remove" is because Windoze has "add/remove". There is no reason for such low-level concepts to be visible to the user.
In my opinion "add" should be executed by clicking on that "run this kool new software" icon shown in your browser, and "remove" should be "stop using the software" (or perhaps you have to drag the icon that appeared on your home page to the trash to get rid of the way of rerunning it).
Why forcing the poor user has to know about "installing" a piece of software. They don't need such knowledge. All they want is "make the machine do this interesting thing". Just because MicroSoft does it does not mean it is user-friendly.
From a practical point, the way to do this is:
Get rid of over-reliance on dynamic libraries by static-linking the binaries to any libraries other than libc and Xlib that you know are on the machine. Or use object services so the program at run-time can complain and perhaps get from the net any missing services, rather than refusing to run with DLL error.
Make the programs work without any "configuration" files (by making them use default values when the files are missing and writing new files when the user saves a configuration).
Make the linkers insert simple binary files in as raw data, so we can imbed large quantities of data into a program without a stupid filter to turn them into C initializers.
You mean people edit those MicroSoft Word documents at the byte level? I didn't know that, I was always under the impression that they cheated with some program called "Word". Well, apparently such cheater programs are not allowed...
Can you point to some documentation for Xft?
Does it do any kind of sharing when a few dozen applications all try to draw the same font? Perhaps this is not necessary nowadays? However this seems to be the obvious reason to put the fonts in the server.
If the X server does not have the render extension, can Xft work at all (even producing very bad output) or does it just abort? Unfortunately I think you better do something about old X servers, otherwise all the applications will do their own kludge, or worse it may discourage use of Xft at all.
Is there a *SIMPLE* font-naming scheme. By "simple" I mean that if I say "Helvetica" I get a font, ALWAYS! It is far, far, far more important that I get a font, and it be the same one every time, than that it actually be the sans-serif font "helvetica". Any scheme where the font names are not user-friendly will make applications and toolkit make their own translation from user-friendly to system names, and they will probably be incompatable with each other. Notice that it is ok to also support "complex" names that specify fonts exactly, as long as simple names are accepted. Also, ALWAYS return a font, no matter what garbage name is thrown at you, you can report an error, but make the best guess anyway.
Can you do anything about UTF-8? It would help a lot if there was a way to render raw UTF-8 strings (and 16 bit unicode while you are at it), and all characters show up. Best answer is to have a 16/8x16 bitmap font containing the entire Unicode set, and any missing letter from a font pulls if from there (clip and center it, don't scale except by integers).
Please draw something, even a box, for every single code. I recommend small "^A" for the control characters.
Draw the MicroSoft "extension" characters for the range 0x80-0xA0. Don't pretend that this is not a standard. It is and there is nothing we can do about it.
The "can't allocate colors" argument is also bullshit. I do not expect antialiased fonts to work without a TrueColor visual anyway, so there is no colormap to worry about!
The Xlib interface is entirely designed to be the same level as the Windows GDI. There is a 1:1 correspondence between the calls in many cases! (Windows copied lots of it, you know). The fact is that X botched the way to specifiy the fonts, so any practical interface requires an enormous and inefficient toolkit that has to enumerate every font on the server to find the correct one (this needs serious fixing with a new font-selection interface). However once you have selected the font you can use the drawing code in Xlib quite easily, without any toolkit wrapper.
Just quit with the lame excuses, and admit that the internal code is such a horrid mess that nobody in 10 years or so has been able to change it to non-binary!
I feel it is inexcusable that they did not hack the existing font mechanism to do antialiased fonts. I want to point out that the much derided MicroSoft managed to add antialiasing to their existing rendering system without requireing the use of new interfaces.
Yes, adding a new and nicer interface is necessary, but they should have made the old interface, which is what existing programs use, work as nice as possible. The fact is that we are not going to see antialiased fonts on the screen for a LONG time even now, because they did not do this.
Installation is not a good measure of ease of use, it is just a significant (perhaps insurmoutable) hurdle that Linux has that Windows does not. If Linux came pre-installed on machines you can bet that "difficulty of installation" would be WAY down the list of problems, like it is for Windows.
I know it will take a time, but the time does not seem to be a problem. On Windoze people are willing to double-click something and wait forever for it to do things like download from web sites, so compilation time is not a problem.
Obviously this "installer" program is a complex pain to write and there would have to be a standard.
As for screenshots, I definately want to see them, they help a lot in figuring out just what a program does.
I totally agree that proper anti-aliasing and other compositing operators must be done in linear space, where the numerical values are equal to the light intensity multiplied by a constant. In my own work I use floating point numbers for this. This is important, as the intensity resolution must be much smaller near zero than away from it, floating point naturally does this, while using integers or fixed point results in huge waste of resolution at the bright end while making huge noticable steps at the black end. All cgi rendering programs work this way, I am working on fixing compositing software to work this way as well.
However, when I take that floating point number and put it into an 8-bit display buffer, I fully expect to "gamma correct" it, rather than do something simple like rint(x*255). (cheap or old cgi rendering software like still does this, completly ruining the realism of the result).
I was under the impression that you were arguing that the circuitry (D/A converter and display device) should be designed such that the output intensity is a constant multiplied by the value stored in the display buffer. As you seem to have a lot of knowledge about this, I must assumme that you are well aware that this is a very inefficient way to use the 8 bits. Ideally those 8-bit numbers should be used in a formula like pow(B,(x/255)-1) to get the intensity displayed on the screen, to get the limited number of intensities as evenly distributed across the "perceptual" scale, which is approximately logarithmic.
Further confusion is that the default behavior of a CRT screen and a linear D/A converter happens to be very close to the ideal for human vision, the gamma curve just happens to be the right power value so that it can be scaled to closely fit the log curve of human vision over the 100:1 or so range of intensities a CRT can display. This was entirely coincidental as it was not a design decision when television was developed.
Because of this coincidence, a good way to improve the display of an 8-bit buffer is to do nothing to the bits before sending them to the screen, this of course conflicts with the assuption that doing something complicated would be better.
Although I think it is stamped out now, around 1990-1994 or so there was a lot of belief that something complicated had to be done between the 8 bits and the CRT, so that nothing complicated had to be done when converting the floating point linear value to 8 bits. This resulted in people trying to "linearize" the monitors, such as the 1.7 gamma still built into Macintoshes, and the SGI software that set the gamma up as high as 2.5, both of these result in horrible banding in the dark areas. People then tried to solve this problem by raising the number of bits, first to 12, and then to 16, trying to get rid of the black banding. Though the extra bits are nice, they are still using them very inefficiently, 16 bits linear just equals the quality of an 8-bit 2.0 gamma display (the step between the bottom two entries is equal), while those same 16 bits used with gamma could give you 256 times as many gray levels!
I have only seen consumer CCD cameras so you may be talking about the internal circuitry or professional equipment, but certainly by the time they output a jpeg image for your photo cd, they have gamma-corrected the image. If they had not done so the display on a home pc through a non-correcting image viewer would be extremely dark. I agree that the CCD itself produces linear response. Also even the first tube cameras required adjustment circuitry, because even though they produced a gamma response, it was a different gamma than the television screens, and the engineers decided (for obvious reasons) to put the expensive adjustment circuitry in the camera rather than in every tv set.
On the eye, I was talking about the reception range of an individual cell, or two adjacent cells, simultaneously, you report this range as 100:1, though I have heard more. You are right that the cells as well as the pupil adjust, I did not know that the cells adjustment is far greater than the pupil, that is pretty interesting. However for our purposes, since all the pixels on the screen are being examined simultaneously, the range of the CRT is approaching that of the eye. My own believe is that we need to get it up to 10000:1 or so before truly realistic scenes can be displayed, as the eye adjusting to look in dark areas is quite natural and we need to stimulate that somewhat to get a fully natural feel.
Why not add a feature when Javascript is turned off (or in a browser that does not understand Javascript at all) that looks for URL's in the Javascript and assummes that a click on that thing is a jump to that URL? This should not be hard and would make the WWW usable without Javascript.
My idea would be to have the from page deleted from the history so that going back goes back to the last page you looked at, and going forward again skips the auto-forward page.
If the auto-forward page is reached from a bookmark perhaps the program should offer to fix your bookmark?
Unrelated, but I have always wanted buttons on the page that say "home" or "back" to work in the history, perhaps by having the browser search up the history for a match to any url it jumps to, and act as though the user selected that item off the history.
The linear/logarithmic/gamma curve I am talking about is a plot from "number put into the display buffer" (called x here, and normalized so 0.0 is the smallest number in the buffer, and 1.0 is the largest number), and the "intensity of light emmitted by the screen" (called y here, and normalized so that 1.0 is maximum the screen + d:a converters produce, and 0.0 is the minimum).
"Linear" in my terminolgy means y = x.
"Gamma" means y = pow(x,G)
"Logarithimic" means y = pow(B,x-1)
The display buffer can only store discreet values, the difference between them is Dx (1/255 for an 8-bit buffer). This will produce descreet steps in the output intensity, the size of these is (approximately) dy/dx * Dx.
My argument is that the best use of this display buffer and hardware is if the perceived steps in output intensity are about equal. This is the only way to minimize the noticability of the steps everywhere.
It is pretty well established that the perceived difference in intensity is a ratio or (y+Dy)/y-1 or Dy/y.
Setting Dy/y to a constant means that dy/dx/y = c or dy/dx = y*C. This is the derivative of a logarithmic curve, which is why I say that a logarithmic curve is the ideal way to map the values in a display buffer to display intensities.
CRT monitors naturally map the voltage level through a gamma curve to the screen intensity, this gamma exponent G is about 1.8. I also propose that this gamma curve, though not equal, is quite close to a logarithimic curve (try drawing both of them in the range 0-1), and certainly MUCH MUCH better than a straight line plotted by a linear function.
Mach banding:
My understanding of the term "Mach banding" is the perception of an "edge" caused by the eye and brain amplifying discontinuities in the first derivative of the intensity across the scene, event though the value is continuous. What I think we are talking about is a discontinuous value, or step in intensity. I have never heard the term "Mach banding" applied to this.
CCD's
Yes CCD's are linear, but you will find that the circuitly in all digital cameras forces that linear output through a lookup table to convert it to a nonlinear value. This is necessary for compatability with all existing binary data formats which are based on binary values that are passed through a gamma function before producing output intensities.
Logarithimic matching exponential
Of course these don't match outside the 0-1 range, but since the monitor is physically incapable of producing these intensities anyway, it does not matter! I know perfectly well that the eye has greater dynamic range than the monitor, though it is not as great as you say if you discount the ability of the iris to reduce/increase exposure, in fact it is only about 1000:1. Inside the 0-1 range I think you will find that the gamma curve matches the exponent much better than a straight line, it is at least curved in the right direction!
References:
Digital Video and HDTV: Pixels, Pictures, and Perception, published by John Wiley & Sons in July, 2000.
Also check Siggraph course notes for Charles Poyntons introduction to color science and color management. It was course # 21 in the New Orleans 2000 Siggraph, but he has done the same course every year for awhile now.
Yes the markup over materials for computer parts is huge (and many orders of magnitude huger for software), but I don't think it is for cars.
If it was for cars, you could buy a car that is a "pirated copy from a Chinese company that got the blueprints somehow". The fact is, this does not happen.
In my experience dynamic linking makes the programs much larger. Dynamic linking cannot win unless more than one program is using the library, and I think for many useful LGPL libraries this is not true. Don't forget that each incompatable version can be considered a different library. Also you can easily tell that a dynamically linked executable takes much more disk space than a stripped static linked executable for a library like mine, where the functions are numerous and fairly small, because the symbols are actually larger than the linked objects! (it is true that these symbols do not take memory when loaded in).
I have also found dynamic linking to be a real pain to support. More than half the makefile is to get around problems with making shared libraries. On Windoze we are forced to add horrible kludges and macros to get around stupidity in VC++ design. Conversely, on Unix we have no ability to share symbols between source files without also bloating the library with another public symbol, and I am forced to arrange the code in weird ways to make as many variables static as possible.
Both systems have the annoying fact that if my library calls another shared library, you need to link that other library, even if you don't link to any functions that use it, this forced us to split the library into a part that uses OpenGL and a part that does not, and also forces me to design it to not call libimage or any other possibly useful library. (I would prefer a shared library system where a call to a missing library produces a crash with "Symbol XYZABC not found")
I can assure you that retaining binary compatability is a huge pain and seriously damages our ability to improve this product. Every change that would break binary compatability is being pushed to version 2.0, even though some of them are trivial (replacing some shorts with ints for widget positions) and have been wanted for more than a year.
And dynamic linking does make it a pain to "install" a program. A lot of useful utilites should be able to be downloaded as a single executable, double-clicked by a user with no permission, and they should work! This means all shared libraries must be installed on the machine, and I'm sorry to say my library is not popular enough that anybody can assumme that!
I actually think dynamic libraries are a mistake, almost all the time. Everybody here laughs at Windoze "DLL hell" but seem to refuse to believe that we are creating the same mess, or worse, on Linux. Dynamic libraries should be reserved for common system interfaces (ie libc). A lot of stuff that is dynamic like OpenGL should be written as a "service" with header files full of macros that shove the correct bytes to the service, and static-linked code to open a socket to the service (and don't complain that sockets are slow, FIX THEM! Also try to design interfaces where return values are not needed all the time, like OpenGL, so that synchronization is not needed and batch transfers can be done).
They also had to give up on NeWS, they were the biggest user of NeWS other than Sun, and in fact used it far better and cleanly merged GL into it.
The problem is that the exact words of the LGPL seem to require dynamic linking of my library, so that it can be "replaced by the user". This imho is unacceptable, since my library is not popular and thus must be provided with the appliacation. This requires the application to be "installed", which greatly reduces it's ease of use. Perhaps more important: it means a programmer cannot modify my library (releasing the code modifications) and use it in their closed program, since the shared library would conflict with other users of my library, this completely defeats one of the main advantages of Open Source, which is that you can change it!
I have taken to adding a disclaimer that says "static linking of my library is allowed, no matter what the LGPL says, and is in fact even encouraged". But I would like to know if there is any better way, or if the LGPL allows this.
I would prefer not to make my own license just because of this, since we have way too many licenses as is, but this worries me no end...
In automobiles it is worth an entire engineer's yearly salary to figure out how to replace a 10-cent widget with a 5-cent one. This saving of 5 cents on a 15,000 dollar item is important because the margin is very small.
Yes there are huge armies of engineers designing the cars, but their cost is still pretty small compared to the materials, labor, shipping, sales commisions, advertising, etc. You have to take into account the enormous numbers of cars sold.