You are talking about Colormaps, while the paper is talking about the CMS (color management) stuff added to the X standard. The CMS stuff was never used, and was a totally stupid idea. Color management should be done by the program, and any system where the 8-bit number chosen by the program does not end up in the image buffer means that true color management is actually impossible, completley reversing the whole purpose of this extension.
Colormaps and Visuals were (and still are) a serious error in X. They have no place in modern graphics and make it very difficult to get a desired color. On older hardware there are obvious alternatives so that the interface could look like true-color, such as using a fixed color cube.
Colormaps were a serious detriment to advancement of graphics. Sun was forced to add several bits to each pixel of their full-color display just to store "which color map" because of the need to support legacy X programs that assummed there was a colormap. At least now most programs that required colormaps are gone, mostly due to the fact that XFree86 did not support them.
Wrong. The problem with X is the seperate window manager.
A resize must be handled by the window manager, which then resizes the window, and then the application notices the window has been resized and draws it's new contents. This is several layers of latency, more importantly there is an unsurmountable asynchronicity between the update of the window border and the window contents that makes this look *really* bad. Try resizing some of the programs that bypass the window manager (some of those music players that have their own window borders) and you will see that the window manager is entirely at fault.
Even under heavy load, if a program drew and handled it's own window borders, all that would happen when you resized is it would "jump" between sizes, but each time it would draw the resized window perfectly. This would be far preferrable to the current behavior.
Windows has the exact same exposure methods and is unbuffered, so you cannot blame that. If you wrote a windows program and looked for PAINT messages you would know this. The transparent windows are a recent addition to Windows and the resizing was better before. For this reason I also don't think this compositing extension will fix these problems on X at all.
The window manager has to be eliminated and we need to return to the X10 design. Let the toolkits draw the borders. Don't cry about "consistency", if that was really important, it has to be solved for the buttons and menus, and thus the window borders are a minor addition. (Also I think "consistency" is far, far over-hyped, really if that was such a big deal then all the real devices on our desks would look identical.)
I'm not sure what you are getting at with the fullscreen stuff.
What does Alt+Tab do on Windows? I just tried it on both a maximized window and a program (Photoshop) that takes over the screen. Like expected it just acts like those are windows and does not resize, remap, or do anything else other than switch the top one.
Most X programs that take over the screen just resize the window contents to the size of the screen. Modern window managers no longer move these, so the contents fill the screen. Then Alt+Tab switches between them, apparently just like Windows. Some window managers don't do Alt+Tab, but then it doesn't work for *any* window, so I still don't understand your complaint.
I have heard that some programs tried to take over the screen by doing override-redirect, which means the window manager cannot see the window and Alt+Tab is impossible. However doing this also completely messes up any modern window manager, for instance making it impossible to send keystrokes to the window, so I kind of doubt anybody is doing that now, and I have never seen such a program.
What the hell is this? Every time, somebody says "Cut and paste", "cut and paste", "cut and paste". Is somebody working off a script out there?
Every new program uses ctrl+X and ctrl+V, the same as Windows! Somebody is sure to point out that those keys don't work in Emacs or in the Terminal. Well I have news for you: they don't work in Emacs or the Terminal on Windows, either! They don't work in Lotus-123! Yet somehow people think they should work in software of the same age on Linux.
Selection and middle-mouse click can be considered a form of drag & drop, with the advantage that you can rearrange windows and open/close them before you drop the selected object, and it is intuitive how to abandon a drag. Now I will be the first to admit that one problem with X is that it only had this drag & drop, and thus people used to Windows or Mac tried to map the clipboard ideas onto it. Imagine if Windows only had drag & drop, and you will see that it could be possible to use, and why people might have gotten confused into thinking this was sufficient.
I'll also question some why you would suggest Alt+C/Alt+P, a combination not used by any program in history!
I just have to state that in my opinion, such ideas will never work, are a waste of huge amounts of effort, and can freeze innovation.
Any such idea requires somehow enumerating all possible user interface actions. I don't believe that is possible, since it assummes that all possible user interface actions have been invented, can be organized into an iterable set, and are known by the small group that would design such a standard.
For instance, if your text editor is going to emulate vi, it must store whether it is in insert or command state. I think it is highly unlikely that anybody designing a text editor who does not actually want a vi interface will do this. Therefore the state must be stored by the configurable user interface. This introduces problems of matching the state to the program (probably it would be best to make it global. All modern vi implementations display the state to help the user, so this display must be provided somewhere, even though the program did not provide any area for it.
By "innovation" I don't mean adding a new tag to PNG. I mean inventing a new way to store the image, for instance in 16-bit floating point. Such an image would be unreadable by older programs or PNG libraries unless an 8-bit version was also supplied, thus wasting the compression of PNG. Even if the PNG library was updated, older programs would still retrieve 8-bit data and lose any advantages of 16-bit data.
I am going to dismiss any such idea out of hand, just like you say. Sorry.
"guidelines" are not the reason OS/X works better. It works better because the graphics system itself is better.
Linux would be a lot better if all the morons who keep asking for "guidelines" and "unification" would stop doing the "fun" stuff and write code to draw anti-aliased shapes or write low-level interface code so that it is easy to create a window and draw into it and get events.
You can write a Mac program that violates every UI "guideline" you want and it will still be easier to write and easier to use.
I think you are confirming what I am saying. This cannot work.
VI is an *OLD* program. It would be easier to rewrite it to just use ctrl+x/v than to rewrite it to use some new "configuration" system.
ALL modern programs that are new enough that the author would consider using a new configuration system already use ctrl+x/v and thus the configuration system is useless. In fact I challenge you to find a single KDE or Gnome program where a plausable configuration system would make them more compatable with each other.
What about programs in the future? Well if they don't come up with new user interface ideas, they can just use ctrl+x/v like modern programs, and again the system is useless. If they do come up with new ideas, well any innovation in user interfaces is by definition going to fall outside what the configuration system can control. Therefore it is useless and would have to be bypassed.
Zero stars = the hardware does not work with Linux. Ie you either receive zero benifit from the hardware or it makes Linux not run.
One star = the hardware will work in some way. A video display that comes up by default in a usable mode will get one star, even if the driver is not specially designed for the hardware at all. If in fact this is reasonably close to the full capabilities of the hardware then it gets 3 stars.
Two stars = There is a driver that works and is better than some default ability of Linux to handle the hardware. Again if in fact this is reasonably close to the full capabilities of the hardware then it gets 3 stars.
Three = Linux is able to use reasonably close to the full capabilities of the hardware and the driver works well.
Four = source code for the driver and/or full documentation for the hardware is available. Notice that the driver may be crummy and for many users they may prefer a three-star thing. Hopefully though such situations will be rare.
Five = source code for the driver and/or full documenation for the hardware is avaiable, and the driver would have gotten 3 stars even if this was not true.
It is important that the existence of any stars is an indication that your hardware will "work".
This is not a joke. Why doesn't somebody go into the damn tty driver and fix it so both ^H and ^? delete backwards. We DON'T need to be able to change this with ioctl calls (just ignore them). While you are at it, eliminate virtually every other programming thing that can be done with ioctl, perhaps limiting it to detecting if they are attempting to set raw mode or not, and maybe guessing if the user prefers VI bindings over Emacs bindings.
The paranoia about back-compatability in Linux is sometimes insane.
Unfortunatly, the folder==window idea *is* a "geeky" idea according to the original poster. It is by far the closest to how the file system actually works. Hierarchial browsers and windows that change contents to new folders are all ideas foisted on us by user-interface experts, while the original way the Mac worked really is the natural, low-level way.
Imagine if an application has a function "Frob". Nobody ever thought of this function before, so it could not possibly be in any standard. But there must be a key that does it, so the app designer decides on a default of Alt+F. Now lets say somebody "customizes" things so Alt+F does forward-search. Oops, we have either lost the ability to "Frob" (possibly making the application useless) or we have moved it to a key that only somebody who deeply understands the customization system could find, or we have ignored the customization for at least one program and make the UI inconsistent. There are NO other possibilities.
Such ideas sound good in abstract but do not work in practice, and make it literally impossible to make new and innovative software, and make debugging the UI very very difficult and often impossible.
The system we have now works: copy ideas people like from one program to another. In case you did not notice, windows and Linux both use ctrl+c/v to copy and paste, and Mac uses command+c/v. This is not a coincidence, and not the result of independent developers arriving at the same results independently.
You are missing the part of the mantra that you have to be able to fix the thing you broke, or at least know how it broke, to understand it.
There is a very large number of people who know how to fix an Outlook Express *installation* when it screws up. Probably more than know how to fix anything else having to do with email. Of course only a small group of engineers at Microsoft can fix Outlook Express itself by changing it's source code, but huge numbers of people know how to "fix" it by changing files and registry entries and server configurations and whatever they can. So in fact Outlook Express proves the point rather than disproving it.
You are talking about the middle-mouse "drag and drop" which was what X originally supported. The data is not put into the "clipboard", it is put into another place called the "selection".
Cut and Paste (using Ctrl+x and Ctrl+v and actually putting the data into the "clipboard") was added in about 1990 at the earliest. Actually it existed since long ago in the X11 and ICCCM design and in Motif, but almost everybody ignored it, due to the horrendous Motif documentation. Random experimentation with XTerm would only reveal the selection, leading a lot of programmers (myself included) to think that you had to fake cut & paste using that. KDE was the first to fix this. Qt followed about a year later. I think all toolkits use the clipboard correctly today.
My mousewheel worked right away. I have heard that some distributions require you to indicate that you have a wheel mouse. This sounds stupid to me, unless I am seriously mistaken the interface to a non-wheel mouse is the same and X will just think you never move the wheel, so there is no need to know this. And yes lots of non-toolkit software ignores the wheel or makes it go backwards.
So they are actually providing worse service for Windows users than Linux users. Linux users can find user-run sites with useful constructive information on how to improve their machines without paying money. The same sites for Windows are buried under 2000 sponsered sites and thus Windows users are unable to get the same service.
Just select the text, type Ctrl+X, go to the other program, and type Ctrl+V. Hmm, how do you do it in Windows?
Oh! It doesn't work in Emacs. Well, I just tried it in Emacs on Windows and oh, my god, it doesn't work there either! Hey, there are literally thousands and thousands of Windows programs where cut & paste does not work. Mostly because they were designed before the current standards came out. Somehow this is not a problem on Windows, but is considered a problem with Linux.
Cut and paste wroks.
Some of your other points are good, but this endless "cut and paste does not work" is getting really annoying and leading me to believe that the people typing these in are working off a script.
This is a bug. If they were aware of the problem they could at least have made the Windows ITunes pop up a box saying that it does not work with this older Ipod, rather than messing up the data on it. In fact that is the fix I would expect from them.
True I have not tried any of the new systems. On older ones getting an rpm to work was almost hopeless, though. I always ended up using -force and making symbolic links to rename older versions of libraries to newer ones to try to fool the software into working, because I had to give up trying to locate them. And it was quite obvious that a lot of the libraries were things like libz that could probably have been statically linked without any great loss.
Even if new systems always find every necessary package and installs it, I still worry that the apparently unlimited amount of interconnected dependencies that people make will mean that loading any application will be the equivalent of downloading and upgrading my entire Linux system. That takes time and is still a bit risky...
No. The customers had no idea they were violating copyright and had good reason to believe they were acting legally. This is also why SCO really can't sue Linux users for anything, and why nobody could sue Windows users when Microsoft was found guilty of copyright violations. More simply, if you read the NYT and a columnist there was found guilty of copyright violations, do you really think you are liable for anything?
Nobody wants the Windows DLL hell where installers replace libraries without you knowing it.
But this does not mean the current Linux "solution" is any better. Really it is pretty much "manual DLL hell" where you have to do every step yourself. The only plausable advantage is that an experienced user can recognize that the next step will screw up their machine and quit before this happens. But for most users it just means a lot of work and an end result that can be just as screwed up as Windows.
What the original writer is requesting is static linking. Or allowing programs to reside in a directory so they can have their own versions of.so files with them (it would help if Linux always added the executable's directory to LD_LIBRARY_PATH but this can be done with little wrapper programs). The advanced users can *try* to replace the.so's, while the average user can use the program, and (horrors) waste a few meg because they did not share a library.
This is true for sharp shadows. But for fuzzy shadows that are being shown here, the correct result from such a diffuse lighting source would be a lighter and wider shadow. It turns out that identical shadows are actually a pretty close emulation because the lightening and widening of the fall-off curve approximately cancel out, and there is obvious speed benefits of implementing them this way.
A simple change to make it more realistic would be to increase the transparency based on the difference in Z. This would improve it far more than changing the width would.
If the "compositing engine" has access to programmable OpenGL shaders there are hacks that can be done that will make very accurate diffuse shadows.
From what I understand, this Xserver solution will not flicker like this. However it could be slow. It could be slow even if there is nothing overlaying the video window.
It sounds like Windows is putting all the fully-opaque windows on the screen and then compositing the visible parts of the transparent ones atop them. Any changes to opaque windows causes the area above to be re-compositied. Thus playing the video causes the overlaying window to flicker. The advantage here is that reading the screen buffer *sort of* works as VNC shows, and hardware that writes to the screen buffer can work. But you get flicker.
This X version would require the video player to always write to the off-screen buffer. This may not be possible with some hardware. More importantly the off-screen buffer must then be copied/composited to the screen. The slowness of this could be a serious problem. The advantage here is that there is no blinking and VNC would work perfectly.
OS/X uses a fixed hardware compositing is done. Thus it is very similar to this X version but because the compositing operation is hard-coded, there may not be the slowness problem.
The "compositing manager" will just be an X11 program. However it will probably call XRender interfaces to composite alpha images, and these *may* be implemented in hardware. Probably not at first, but it will happen.
Slashdot Mirror
You are talking about Colormaps, while the paper is talking about the CMS (color management) stuff added to the X standard. The CMS stuff was never used, and was a totally stupid idea. Color management should be done by the program, and any system where the 8-bit number chosen by the program does not end up in the image buffer means that true color management is actually impossible, completley reversing the whole purpose of this extension.
Colormaps and Visuals were (and still are) a serious error in X. They have no place in modern graphics and make it very difficult to get a desired color. On older hardware there are obvious alternatives so that the interface could look like true-color, such as using a fixed color cube.
Colormaps were a serious detriment to advancement of graphics. Sun was forced to add several bits to each pixel of their full-color display just to store "which color map" because of the need to support legacy X programs that assummed there was a colormap. At least now most programs that required colormaps are gone, mostly due to the fact that XFree86 did not support them.
Wrong. The problem with X is the seperate window manager.
A resize must be handled by the window manager, which then resizes the window, and then the application notices the window has been resized and draws it's new contents. This is several layers of latency, more importantly there is an unsurmountable asynchronicity between the update of the window border and the window contents that makes this look *really* bad. Try resizing some of the programs that bypass the window manager (some of those music players that have their own window borders) and you will see that the window manager is entirely at fault.
Even under heavy load, if a program drew and handled it's own window borders, all that would happen when you resized is it would "jump" between sizes, but each time it would draw the resized window perfectly. This would be far preferrable to the current behavior.
Windows has the exact same exposure methods and is unbuffered, so you cannot blame that. If you wrote a windows program and looked for PAINT messages you would know this. The transparent windows are a recent addition to Windows and the resizing was better before. For this reason I also don't think this compositing extension will fix these problems on X at all.
The window manager has to be eliminated and we need to return to the X10 design. Let the toolkits draw the borders. Don't cry about "consistency", if that was really important, it has to be solved for the buttons and menus, and thus the window borders are a minor addition. (Also I think "consistency" is far, far over-hyped, really if that was such a big deal then all the real devices on our desks would look identical.)
I'm not sure what you are getting at with the fullscreen stuff.
What does Alt+Tab do on Windows? I just tried it on both a maximized window and a program (Photoshop) that takes over the screen. Like expected it just acts like those are windows and does not resize, remap, or do anything else other than switch the top one.
Most X programs that take over the screen just resize the window contents to the size of the screen. Modern window managers no longer move these, so the contents fill the screen. Then Alt+Tab switches between them, apparently just like Windows. Some window managers don't do Alt+Tab, but then it doesn't work for *any* window, so I still don't understand your complaint.
I have heard that some programs tried to take over the screen by doing override-redirect, which means the window manager cannot see the window and Alt+Tab is impossible. However doing this also completely messes up any modern window manager, for instance making it impossible to send keystrokes to the window, so I kind of doubt anybody is doing that now, and I have never seen such a program.
What the hell is this? Every time, somebody says "Cut and paste", "cut and paste", "cut and paste". Is somebody working off a script out there?
Every new program uses ctrl+X and ctrl+V, the same as Windows! Somebody is sure to point out that those keys don't work in Emacs or in the Terminal. Well I have news for you: they don't work in Emacs or the Terminal on Windows, either! They don't work in Lotus-123! Yet somehow people think they should work in software of the same age on Linux.
Selection and middle-mouse click can be considered a form of drag & drop, with the advantage that you can rearrange windows and open/close them before you drop the selected object, and it is intuitive how to abandon a drag. Now I will be the first to admit that one problem with X is that it only had this drag & drop, and thus people used to Windows or Mac tried to map the clipboard ideas onto it. Imagine if Windows only had drag & drop, and you will see that it could be possible to use, and why people might have gotten confused into thinking this was sufficient.
I'll also question some why you would suggest Alt+C/Alt+P, a combination not used by any program in history!
I just have to state that in my opinion, such ideas will never work, are a waste of huge amounts of effort, and can freeze innovation.
Any such idea requires somehow enumerating all possible user interface actions. I don't believe that is possible, since it assummes that all possible user interface actions have been invented, can be organized into an iterable set, and are known by the small group that would design such a standard.
For instance, if your text editor is going to emulate vi, it must store whether it is in insert or command state. I think it is highly unlikely that anybody designing a text editor who does not actually want a vi interface will do this. Therefore the state must be stored by the configurable user interface. This introduces problems of matching the state to the program (probably it would be best to make it global. All modern vi implementations display the state to help the user, so this display must be provided somewhere, even though the program did not provide any area for it.
By "innovation" I don't mean adding a new tag to PNG. I mean inventing a new way to store the image, for instance in 16-bit floating point. Such an image would be unreadable by older programs or PNG libraries unless an 8-bit version was also supplied, thus wasting the compression of PNG. Even if the PNG library was updated, older programs would still retrieve 8-bit data and lose any advantages of 16-bit data.
I am going to dismiss any such idea out of hand, just like you say. Sorry.
Linux would be a lot better if all the morons who keep asking for "guidelines" and "unification" would stop doing the "fun" stuff and write code to draw anti-aliased shapes or write low-level interface code so that it is easy to create a window and draw into it and get events.
You can write a Mac program that violates every UI "guideline" you want and it will still be easier to write and easier to use.
I think you are confirming what I am saying. This cannot work.
VI is an *OLD* program. It would be easier to rewrite it to just use ctrl+x/v than to rewrite it to use some new "configuration" system.
ALL modern programs that are new enough that the author would consider using a new configuration system already use ctrl+x/v and thus the configuration system is useless. In fact I challenge you to find a single KDE or Gnome program where a plausable configuration system would make them more compatable with each other.
What about programs in the future? Well if they don't come up with new user interface ideas, they can just use ctrl+x/v like modern programs, and again the system is useless. If they do come up with new ideas, well any innovation in user interfaces is by definition going to fall outside what the configuration system can control. Therefore it is useless and would have to be bypassed.
Zero stars = the hardware does not work with Linux. Ie you either receive zero benifit from the hardware or it makes Linux not run.
One star = the hardware will work in some way. A video display that comes up by default in a usable mode will get one star, even if the driver is not specially designed for the hardware at all. If in fact this is reasonably close to the full capabilities of the hardware then it gets 3 stars.
Two stars = There is a driver that works and is better than some default ability of Linux to handle the hardware. Again if in fact this is reasonably close to the full capabilities of the hardware then it gets 3 stars.
Three = Linux is able to use reasonably close to the full capabilities of the hardware and the driver works well.
Four = source code for the driver and/or full documentation for the hardware is available. Notice that the driver may be crummy and for many users they may prefer a three-star thing. Hopefully though such situations will be rare.
Five = source code for the driver and/or full documenation for the hardware is avaiable, and the driver would have gotten 3 stars even if this was not true.
It is important that the existence of any stars is an indication that your hardware will "work".
This is not a joke. Why doesn't somebody go into the damn tty driver and fix it so both ^H and ^? delete backwards. We DON'T need to be able to change this with ioctl calls (just ignore them). While you are at it, eliminate virtually every other programming thing that can be done with ioctl, perhaps limiting it to detecting if they are attempting to set raw mode or not, and maybe guessing if the user prefers VI bindings over Emacs bindings.
The paranoia about back-compatability in Linux is sometimes insane.
Unfortunatly, the folder==window idea *is* a "geeky" idea according to the original poster. It is by far the closest to how the file system actually works. Hierarchial browsers and windows that change contents to new folders are all ideas foisted on us by user-interface experts, while the original way the Mac worked really is the natural, low-level way.
Imagine if an application has a function "Frob". Nobody ever thought of this function before, so it could not possibly be in any standard. But there must be a key that does it, so the app designer decides on a default of Alt+F. Now lets say somebody "customizes" things so Alt+F does forward-search. Oops, we have either lost the ability to "Frob" (possibly making the application useless) or we have moved it to a key that only somebody who deeply understands the customization system could find, or we have ignored the customization for at least one program and make the UI inconsistent. There are NO other possibilities.
Such ideas sound good in abstract but do not work in practice, and make it literally impossible to make new and innovative software, and make debugging the UI very very difficult and often impossible.
The system we have now works: copy ideas people like from one program to another. In case you did not notice, windows and Linux both use ctrl+c/v to copy and paste, and Mac uses command+c/v. This is not a coincidence, and not the result of independent developers arriving at the same results independently.
You are missing the part of the mantra that you have to be able to fix the thing you broke, or at least know how it broke, to understand it.
There is a very large number of people who know how to fix an Outlook Express *installation* when it screws up. Probably more than know how to fix anything else having to do with email. Of course only a small group of engineers at Microsoft can fix Outlook Express itself by changing it's source code, but huge numbers of people know how to "fix" it by changing files and registry entries and server configurations and whatever they can. So in fact Outlook Express proves the point rather than disproving it.
You are talking about the middle-mouse "drag and drop" which was what X originally supported. The data is not put into the "clipboard", it is put into another place called the "selection".
Cut and Paste (using Ctrl+x and Ctrl+v and actually putting the data into the "clipboard") was added in about 1990 at the earliest. Actually it existed since long ago in the X11 and ICCCM design and in Motif, but almost everybody ignored it, due to the horrendous Motif documentation. Random experimentation with XTerm would only reveal the selection, leading a lot of programmers (myself included) to think that you had to fake cut & paste using that. KDE was the first to fix this. Qt followed about a year later. I think all toolkits use the clipboard correctly today.
My mousewheel worked right away. I have heard that some distributions require you to indicate that you have a wheel mouse. This sounds stupid to me, unless I am seriously mistaken the interface to a non-wheel mouse is the same and X will just think you never move the wheel, so there is no need to know this. And yes lots of non-toolkit software ignores the wheel or makes it go backwards.
So they are actually providing worse service for Windows users than Linux users. Linux users can find user-run sites with useful constructive information on how to improve their machines without paying money. The same sites for Windows are buried under 2000 sponsered sites and thus Windows users are unable to get the same service.
They are required to say that to get the OEM discount on Windows.
Just select the text, type Ctrl+X, go to the other program, and type Ctrl+V. Hmm, how do you do it in Windows?
Oh! It doesn't work in Emacs. Well, I just tried it in Emacs on Windows and oh, my god, it doesn't work there either! Hey, there are literally thousands and thousands of Windows programs where cut & paste does not work. Mostly because they were designed before the current standards came out. Somehow this is not a problem on Windows, but is considered a problem with Linux.
Cut and paste wroks.
Some of your other points are good, but this endless "cut and paste does not work" is getting really annoying and leading me to believe that the people typing these in are working off a script.
PS: my wheel mouse works just fine.
This is a bug. If they were aware of the problem they could at least have made the Windows ITunes pop up a box saying that it does not work with this older Ipod, rather than messing up the data on it. In fact that is the fix I would expect from them.
Yes I would agree that under those circumstances the buyer could be sued.
True I have not tried any of the new systems. On older ones getting an rpm to work was almost hopeless, though. I always ended up using -force and making symbolic links to rename older versions of libraries to newer ones to try to fool the software into working, because I had to give up trying to locate them. And it was quite obvious that a lot of the libraries were things like libz that could probably have been statically linked without any great loss.
Even if new systems always find every necessary package and installs it, I still worry that the apparently unlimited amount of interconnected dependencies that people make will mean that loading any application will be the equivalent of downloading and upgrading my entire Linux system. That takes time and is still a bit risky...
No. The customers had no idea they were violating copyright and had good reason to believe they were acting legally. This is also why SCO really can't sue Linux users for anything, and why nobody could sue Windows users when Microsoft was found guilty of copyright violations. More simply, if you read the NYT and a columnist there was found guilty of copyright violations, do you really think you are liable for anything?
This is also why "indemification" is meaningless.
Nobody wants the Windows DLL hell where installers replace libraries without you knowing it.
.so files with them (it would help if Linux always added the executable's directory to LD_LIBRARY_PATH but this can be done with little wrapper programs). The advanced users can *try* to replace the .so's, while the average user can use the program, and (horrors) waste a few meg because they did not share a library.
But this does not mean the current Linux "solution" is any better. Really it is pretty much "manual DLL hell" where you have to do every step yourself. The only plausable advantage is that an experienced user can recognize that the next step will screw up their machine and quit before this happens. But for most users it just means a lot of work and an end result that can be just as screwed up as Windows.
What the original writer is requesting is static linking. Or allowing programs to reside in a directory so they can have their own versions of
This is true for sharp shadows. But for fuzzy shadows that are being shown here, the correct result from such a diffuse lighting source would be a lighter and wider shadow. It turns out that identical shadows are actually a pretty close emulation because the lightening and widening of the fall-off curve approximately cancel out, and there is obvious speed benefits of implementing them this way.
A simple change to make it more realistic would be to increase the transparency based on the difference in Z. This would improve it far more than changing the width would.
If the "compositing engine" has access to programmable OpenGL shaders there are hacks that can be done that will make very accurate diffuse shadows.
Or ask them if they also think the ability to read files on remote machines is slowing down their local disk access.
From what I understand, this Xserver solution will not flicker like this. However it could be slow. It could be slow even if there is nothing overlaying the video window.
It sounds like Windows is putting all the fully-opaque windows on the screen and then compositing the visible parts of the transparent ones atop them. Any changes to opaque windows causes the area above to be re-compositied. Thus playing the video causes the overlaying window to flicker. The advantage here is that reading the screen buffer *sort of* works as VNC shows, and hardware that writes to the screen buffer can work. But you get flicker.
This X version would require the video player to always write to the off-screen buffer. This may not be possible with some hardware. More importantly the off-screen buffer must then be copied/composited to the screen. The slowness of this could be a serious problem. The advantage here is that there is no blinking and VNC would work perfectly.
OS/X uses a fixed hardware compositing is done. Thus it is very similar to this X version but because the compositing operation is hard-coded, there may not be the slowness problem.
The "compositing manager" will just be an X11 program. However it will probably call XRender interfaces to composite alpha images, and these *may* be implemented in hardware. Probably not at first, but it will happen.