What about the buttons and scrollbars and every other widget in your applications? Why is it ok for these to be drawn by the clients, but not the "window decorations".
Historical cruft is not a good excuse. A solution that fixes every widget (often called an "appearance library") is better, and one of the big obstuctions for this in X (and Windows) is that the window borders are drawn by a totally different subsystem than every other widget.
Also you have certainly never worked with ICCCM and/or the new WM hints api in X11, or you would know what a horrible mess it is to have part of the image drawn by a different process than your program.
No, wayland will require the decorations to be drawn by the client side into the window image. The wayland server cannot draw into these images and any other solution would have the same problems as X11 (unnecessary extra surface for the decorations, requirements that the border between content/decoration be a rectangle, insane complex api to update the decorations, and ugly asynchronous update between the border and contents when windows are resized).
In KDE the window borders will be drawn by Qt, and thus for most applications they are "drawn by the system". Note that this is how the buttons, scrollbars, and every other widget is drawn. The endless panic response that "the window borders will look different and that will confuse(TM) the user!!!!!!" seem to ignore that this has been either solved or not really a problem for buttons. Tell me the last time you could not figure out how to push a button because "it looked different".
Wayland has a ping api so that non-responsive applications can be detected. You will be able to move, raise/lower, iconize/deiconize, select, and kill non-responsive applications. You will not be able to resize them (unless it does a crude simulation by scaling or clipping the image).
This is already much better than Windows because it was designed for this from the start. I believe new Windows api has added something similar but they still have to run legacy programs.
X11 wire protocol is asynchronous, but the majority of xlib calls are effectively synchronous, because they wait for a return value from the server (send asynchronously over the wire) before they return. The only thing that is actually async is the drawing api, the very part that is not used by modern X applications. Modern ones (including any using Cairo) draw into a local image and then copy that image to the server, because that is less data than all the calls to set individual pixels on the server that they would otherwise have to use. At the time X was designed drawing images was considered a horrifically expensive operation for only the top-most workstations and it actually requires *several* sequential synchronous calls.
Tearing is certainly a problem with X11 because it lacks an "I am done drawing the window" call that the server can use as an indicator as to when it can actually sync with the vertical retrace. Apparently the internal design of X11 is quite a mess because this has not been ever added despite the obvious usefulness.
Tearing is also caused by the seperate window manager drawing the borders from the clients drawing the contents. It is IMPOSSIBLE to make this work without glitches. Notice that increasing machine speeds by hundreds of times in the last 30 years has not fixed it.
Those toolkits *DO* support backing store. You obviously have not tried to program with XLib or you would know how much of an incredible pain it is to do this in any way that is not horribly slow. Hint: do not use XDBR as it is slower than using your own pixmap and copying it. What you really want is shared DRI (sp?) buffers but setting that up is horribly complicated.
Wayland's main purpose is to assume that backing store is the way every window draws and should be the fastest method.
The main reason for better graphics on Windows:
1. Window borders are drawn by the clients. This removes the async and mismatch between the borders and contents when you resize windows and move them. Also allows decorations to be drawn on windows. If you don't think this is a big deal, compare on Linux one of the border-less media players. Notice how smooth moving and resizing the media player is compared to most apps. This is entirely due to the avoidance of the window manager drawing and interaction, note that those media players are probably drawing much more complicated graphics and probably not that efficiently.
2. Easy(er) to create a local image buffer and get it reliably and QUICKLY copied or moved to where the on-screen compositor can combine all the windows to the final screen image. In X even the best methods require copying the data several times. I suspect Windows manages to mmap that image from the client's memory to the screen compositor's memory. About 90% of wayland's design is dedicated to doing this. I am unsure as I don't program Windows but I suspect the way to create such an image without using a toolkit is enormously painful, while still being 10x better than X11. Wayland from what I have seen has made it doable in a few lines (one call to properly allocate the memory so that it can be mapped to the graphics card, and a second to tell wayland to use it as the screen image).
3. Better artists on Windows. Though artwork is portable.
4. Fonts that rely on Windows-specific rasterizer bugs. These also screw up on OSX and Android.
Wayland does exactly that and should be very good at network transparency.
Yes it sends images of the windows. This is a win because it is much much simpler than any scene description and it will not be obsolete 1 year from now. It does seem like it is more data, but for modern GUI that is in fact the most efficient way to represent the picture being drawn. You are aware that many modern apis draw MORE than one polygon per pixel?
Advantages over how X11 does images is that it avoids round trips and does not require perfect end result images, allowing compression. It also has the necessary calls to do incremental update (ie the client can say what part of the window has changed since last time, something missing from X11 images).
I think this is mostly equivalent to how patents work for pharma now, and does not use patents:
You are required to have a license to sell or distribute a drug. The government grants these licenses. One of the requirements for getting the license is that all the testing required by the FDA be done.
Because that testing takes a long time, the government promises that it will not grant a license to anybody other than the first applicant for some number of years (17? same as patents). Like patents, license applications are made public, but perhaps unlike them there is a delay while they remain secret, this is to prevent companies from delaying while trying to locate all possible variations so they can submit them all at once.
Big difference from patents: if the applicant does not prove that they are actively working on doing the testing and other requirements for the license, or that they are actually going to manufacture and distribute the drug, then they lose the license. And if the license holder stops manufacture and distribution, they lose the license. Then anybody else can apply for a license.
Let's say you invent some cool widget but don't own your own manufacturing facility to produce it. So you go to a factory and pay them to make your widgets. Oops... they have a "production problem" and your product will be delayed. In the mean time, taking your plans, they run their own production and get their own version out into the marketplace before they even ship your product.
You can write up a contract for doing the manufacturing that does not allow them to do this.
What *does* work is what it sounds like you are asking for. The Linux machine can run the Gnome/KDE program and display it on the X server on your Windows machine. It will show up in a window on your desktop.
Possibly you were confused by what is a problem: if you wanted to take some KDE or Gnome program and *run* it on your Windows machine (ie *not* over the network from your Linux machine), you would think all that is needed is the X server and to recompile the program. Or maybe you think you might also need cygwin installed before you compile. You will quickly find that you also need to install *huge* amounts of stuff, pretty much the entire KDE/Gnome desktop set of libraries, before the program will compile. In fact X is probably the only thing you *don't* need (GTK can be compiled to call WIN32 directly). This is a certainly a PITA but is not exactly the problem you described.
More to the point, the trees being cut are mostly Ficus trees which destroy sidewalks and cost the city a huge amount of money, and they are not in any way original or ancient (they were popular because they grow really fast). They are to be replaced with twice as many trees, of different species that do not have invasive surface roots.
So he argues that Mac OS X has not displaced Linux because its overall marketshare has only gone from 5 to 7.5%? That seems to be an odd conclusion. That growth is nearly twice the entire Linux marketshare according to his cited numbers.
No his conclusion makes sense for precisely this reason. If OS X increased by more than Linux's share, than the increase cannot be explained by Linux users switching to OS X. Thus there are other reasons besides Linux that users switch to OS X.
The astronomer and physics professor who developed the big bang theory was also a priest.
He was a Jesuit, actually. It would help to identify the religions, as they do differ from each other.
Yes Catholic and Jesuit college-level schools are really excellent in science. I don't think that was the type of "religious school" the GP was talking about. You don't send 8 year olds there.
The wayland compositor is restricted to OpenGL ES.
But applications can use any rendering library they want to draw into their window images. Thus full OpenGL if they want.
The biggest trick is that the window image must be in gpu memory where OpenGL can draw into with hardware acceleration. But wayland allows this to be set up.
The server is able to control where the buffers are allocated. If the server needs to read them then it will place them in memory that can be read.
You have to face the fact that current X applications are acting exactly like this. The ONLY drawing api they use is XDrawImage. I can assure you that X does not magically make this fast over the network. Wayland is designed to implement this necessary api fast and cleanly. I believe Wayland's design will allow lossy compression of the images, something that cannot be done by X now (it can be done by full-desktop rdp but that is not what anybody wants).
You may be right about it being a good idea for Qt itself to not throw exceptions.
However what programmers (at least me) want is to be able to throw exceptions in message handlers and have them caught by the code that sent the message. It is not Qt throwing them, I just want them to pass cleanly through.
We have had very good results with assuming that std::exception is the "top" as he calls it.
The non-std::exceptions are limited and in fact indicate cases where we *must* catch it, or where they should not occur except inside a catch. One is boost::thread_interrupted, which should only be thrown inside a boost thread and thus inside a catch for it. Another is a special exception we have for a "cancelled" dialog box, which must be caught so that the user cancelling a dialog box does not pop up an error-reporting dialog.
This is nowhere near as bad as the initial poster makes out.
I can imagine problems if arbitrary 3rd-party libraries are used, but even then we are seeing std::exception used.
Having made a cross-platform toolkit I believe the blame for Qt's bad handling of exceptions is due to the WIN32 api. It is impossible (at least with earlier C++) to propagate an exception from an event handler back to the code that called "wait_for_event()". This is trivial in the X api, and not really difficult with OSX. My toolkit (FLTK) "fixed" this by translating all exceptions in WIN32 into the same "an exception was thrown" exception, which is hardly a fix because it is incompatible with the X version. I can't blame Qt for just saying that exceptions should not be used.
You do know you can use hardware acceleration to draw into an OpenGL texture, right?
I am a bit confused as to what you are arguing for. I agree that Qt widgets are vastly overweight, and a redesign that makes it practical to have many orders of magnitude more widgets representing much simpler objects such as lines would be more efficient and powerful, and this is what the newer designs are attempting. But it has nothing to do with moving the drawing to hardware acceleration.
Actually Curiosity will be slower than Spirit/Opportunity, according to the pdf I read. However it is able to get over obstacles that would have stopped the older ones.
Cars are designed to *maximize the efficiency at a certain speed*, such as 50mph. This does NOT mean that is the most efficient speed. The car could very well still be most efficient at 20mph even though the engineers concentrated on raising the 50mph efficiency. All they did was get it closer to the 20mph efficiency. And this makes perfect sense both from an environmental and a commercial pov, but it should not be misread as saying that you will save gas by increasing to the designed speed.
Slashdot Mirror
What about the buttons and scrollbars and every other widget in your applications? Why is it ok for these to be drawn by the clients, but not the "window decorations".
Historical cruft is not a good excuse. A solution that fixes every widget (often called an "appearance library") is better, and one of the big obstuctions for this in X (and Windows) is that the window borders are drawn by a totally different subsystem than every other widget.
Also you have certainly never worked with ICCCM and/or the new WM hints api in X11, or you would know what a horrible mess it is to have part of the image drawn by a different process than your program.
No, wayland will require the decorations to be drawn by the client side into the window image. The wayland server cannot draw into these images and any other solution would have the same problems as X11 (unnecessary extra surface for the decorations, requirements that the border between content/decoration be a rectangle, insane complex api to update the decorations, and ugly asynchronous update between the border and contents when windows are resized).
In KDE the window borders will be drawn by Qt, and thus for most applications they are "drawn by the system". Note that this is how the buttons, scrollbars, and every other widget is drawn. The endless panic response that "the window borders will look different and that will confuse(TM) the user!!!!!!" seem to ignore that this has been either solved or not really a problem for buttons. Tell me the last time you could not figure out how to push a button because "it looked different".
Wayland has a ping api so that non-responsive applications can be detected. You will be able to move, raise/lower, iconize/deiconize, select, and kill non-responsive applications. You will not be able to resize them (unless it does a crude simulation by scaling or clipping the image).
This is already much better than Windows because it was designed for this from the start. I believe new Windows api has added something similar but they still have to run legacy programs.
X11 wire protocol is asynchronous, but the majority of xlib calls are effectively synchronous, because they wait for a return value from the server (send asynchronously over the wire) before they return. The only thing that is actually async is the drawing api, the very part that is not used by modern X applications. Modern ones (including any using Cairo) draw into a local image and then copy that image to the server, because that is less data than all the calls to set individual pixels on the server that they would otherwise have to use. At the time X was designed drawing images was considered a horrifically expensive operation for only the top-most workstations and it actually requires *several* sequential synchronous calls.
Tearing is certainly a problem with X11 because it lacks an "I am done drawing the window" call that the server can use as an indicator as to when it can actually sync with the vertical retrace. Apparently the internal design of X11 is quite a mess because this has not been ever added despite the obvious usefulness.
Tearing is also caused by the seperate window manager drawing the borders from the clients drawing the contents. It is IMPOSSIBLE to make this work without glitches. Notice that increasing machine speeds by hundreds of times in the last 30 years has not fixed it.
Those toolkits *DO* support backing store. You obviously have not tried to program with XLib or you would know how much of an incredible pain it is to do this in any way that is not horribly slow. Hint: do not use XDBR as it is slower than using your own pixmap and copying it. What you really want is shared DRI (sp?) buffers but setting that up is horribly complicated.
Wayland's main purpose is to assume that backing store is the way every window draws and should be the fastest method.
The main reason for better graphics on Windows:
1. Window borders are drawn by the clients. This removes the async and mismatch between the borders and contents when you resize windows and move them. Also allows decorations to be drawn on windows. If you don't think this is a big deal, compare on Linux one of the border-less media players. Notice how smooth moving and resizing the media player is compared to most apps. This is entirely due to the avoidance of the window manager drawing and interaction, note that those media players are probably drawing much more complicated graphics and probably not that efficiently.
2. Easy(er) to create a local image buffer and get it reliably and QUICKLY copied or moved to where the on-screen compositor can combine all the windows to the final screen image. In X even the best methods require copying the data several times. I suspect Windows manages to mmap that image from the client's memory to the screen compositor's memory. About 90% of wayland's design is dedicated to doing this. I am unsure as I don't program Windows but I suspect the way to create such an image without using a toolkit is enormously painful, while still being 10x better than X11. Wayland from what I have seen has made it doable in a few lines (one call to properly allocate the memory so that it can be mapped to the graphics card, and a second to tell wayland to use it as the screen image).
3. Better artists on Windows. Though artwork is portable.
4. Fonts that rely on Windows-specific rasterizer bugs. These also screw up on OSX and Android.
Wayland does exactly that and should be very good at network transparency.
Yes it sends images of the windows. This is a win because it is much much simpler than any scene description and it will not be obsolete 1 year from now. It does seem like it is more data, but for modern GUI that is in fact the most efficient way to represent the picture being drawn. You are aware that many modern apis draw MORE than one polygon per pixel?
Advantages over how X11 does images is that it avoids round trips and does not require perfect end result images, allowing compression. It also has the necessary calls to do incremental update (ie the client can say what part of the window has changed since last time, something missing from X11 images).
Car companies don't make cars. They just rearrange molecules until they are formed into a car shape.
Yes but those people are not going to be stopped by patents either!
I think this is mostly equivalent to how patents work for pharma now, and does not use patents:
You are required to have a license to sell or distribute a drug. The government grants these licenses. One of the requirements for getting the license is that all the testing required by the FDA be done.
Because that testing takes a long time, the government promises that it will not grant a license to anybody other than the first applicant for some number of years (17? same as patents). Like patents, license applications are made public, but perhaps unlike them there is a delay while they remain secret, this is to prevent companies from delaying while trying to locate all possible variations so they can submit them all at once.
Big difference from patents: if the applicant does not prove that they are actively working on doing the testing and other requirements for the license, or that they are actually going to manufacture and distribute the drug, then they lose the license. And if the license holder stops manufacture and distribution, they lose the license. Then anybody else can apply for a license.
Let's say you invent some cool widget but don't own your own manufacturing facility to produce it. So you go to a factory and pay them to make your widgets. Oops... they have a "production problem" and your product will be delayed. In the mean time, taking your plans, they run their own production and get their own version out into the marketplace before they even ship your product.
You can write up a contract for doing the manufacturing that does not allow them to do this.
Have you been to an eye doctor to see about this problem? It sounds pretty serious.
You seem to have gotten the wrong story.
What *does* work is what it sounds like you are asking for. The Linux machine can run the Gnome/KDE program and display it on the X server on your Windows machine. It will show up in a window on your desktop.
Possibly you were confused by what is a problem: if you wanted to take some KDE or Gnome program and *run* it on your Windows machine (ie *not* over the network from your Linux machine), you would think all that is needed is the X server and to recompile the program. Or maybe you think you might also need cygwin installed before you compile. You will quickly find that you also need to install *huge* amounts of stuff, pretty much the entire KDE/Gnome desktop set of libraries, before the program will compile. In fact X is probably the only thing you *don't* need (GTK can be compiled to call WIN32 directly). This is a certainly a PITA but is not exactly the problem you described.
More to the point, the trees being cut are mostly Ficus trees which destroy sidewalks and cost the city a huge amount of money, and they are not in any way original or ancient (they were popular because they grow really fast). They are to be replaced with twice as many trees, of different species that do not have invasive surface roots.
Just run ROT13 twice for double the encryption!
So he argues that Mac OS X has not displaced Linux because its overall marketshare has only gone from 5 to 7.5%? That seems to be an odd conclusion. That growth is nearly twice the entire Linux marketshare according to his cited numbers.
No his conclusion makes sense for precisely this reason. If OS X increased by more than Linux's share, than the increase cannot be explained by Linux users switching to OS X. Thus there are other reasons besides Linux that users switch to OS X.
The astronomer and physics professor who developed the big bang theory was also a priest.
He was a Jesuit, actually. It would help to identify the religions, as they do differ from each other.
Yes Catholic and Jesuit college-level schools are really excellent in science. I don't think that was the type of "religious school" the GP was talking about. You don't send 8 year olds there.
The wayland compositor is restricted to OpenGL ES.
But applications can use any rendering library they want to draw into their window images. Thus full OpenGL if they want.
The biggest trick is that the window image must be in gpu memory where OpenGL can draw into with hardware acceleration. But wayland allows this to be set up.
The server is able to control where the buffers are allocated. If the server needs to read them then it will place them in memory that can be read.
You have to face the fact that current X applications are acting exactly like this. The ONLY drawing api they use is XDrawImage. I can assure you that X does not magically make this fast over the network. Wayland is designed to implement this necessary api fast and cleanly. I believe Wayland's design will allow lossy compression of the images, something that cannot be done by X now (it can be done by full-desktop rdp but that is not what anybody wants).
Wayland does not call X11.
The X11 emulation on wayland will call wayland.
You may be right about it being a good idea for Qt itself to not throw exceptions.
However what programmers (at least me) want is to be able to throw exceptions in message handlers and have them caught by the code that sent the message. It is not Qt throwing them, I just want them to pass cleanly through.
We have had very good results with assuming that std::exception is the "top" as he calls it.
The non-std::exceptions are limited and in fact indicate cases where we *must* catch it, or where they should not occur except inside a catch. One is boost::thread_interrupted, which should only be thrown inside a boost thread and thus inside a catch for it. Another is a special exception we have for a "cancelled" dialog box, which must be caught so that the user cancelling a dialog box does not pop up an error-reporting dialog.
This is nowhere near as bad as the initial poster makes out.
I can imagine problems if arbitrary 3rd-party libraries are used, but even then we are seeing std::exception used.
Having made a cross-platform toolkit I believe the blame for Qt's bad handling of exceptions is due to the WIN32 api. It is impossible (at least with earlier C++) to propagate an exception from an event handler back to the code that called "wait_for_event()". This is trivial in the X api, and not really difficult with OSX. My toolkit (FLTK) "fixed" this by translating all exceptions in WIN32 into the same "an exception was thrown" exception, which is hardly a fix because it is incompatible with the X version. I can't blame Qt for just saying that exceptions should not be used.
You do know you can use hardware acceleration to draw into an OpenGL texture, right?
I am a bit confused as to what you are arguing for. I agree that Qt widgets are vastly overweight, and a redesign that makes it practical to have many orders of magnitude more widgets representing much simpler objects such as lines would be more efficient and powerful, and this is what the newer designs are attempting. But it has nothing to do with moving the drawing to hardware acceleration.
It sounds like either the Nvidia driver there does not have this bug, or it does have the bug but nobody has discovered it yet.
Actually Curiosity will be slower than Spirit/Opportunity, according to the pdf I read. However it is able to get over obstacles that would have stopped the older ones.
Cars are designed to *maximize the efficiency at a certain speed*, such as 50mph. This does NOT mean that is the most efficient speed. The car could very well still be most efficient at 20mph even though the engineers concentrated on raising the 50mph efficiency. All they did was get it closer to the 20mph efficiency. And this makes perfect sense both from an environmental and a commercial pov, but it should not be misread as saying that you will save gas by increasing to the designed speed.