KDE and Canonical Developers Disagree Over Display Server 202
sfcrazy (1542989) writes "Robert Ancell, a Canonical software engineer, wrote a blog titled 'Why the display server doesn't matter', arguing that: 'Display servers are the component in the display stack that seems to hog a lot of the limelight. I think this is a bit of a mistake, as it’s actually probably the least important component, at least to a user.' KDE developers, who do have long experience with Qt (something Canonical is moving towards for its mobile ambitions), have refuted Bob's claims and said that display server does matter."
So why did Apple and Google toss it? (Score:5, Interesting)
Re:So why did Apple and Google toss it? (Score:3, Interesting)
And both are now incompatible ecosystems. Do we want to repeat this nonsense?
Re:So why did Apple and Google toss it? (Score:4, Interesting)
WRT to OSX, there is history. Back in the days of NeXT, Jobs & co. decided to use Display Postscript for a variety of reasons. A few of the reasons: X back then was huge, ungainly and a total beast to work with using the limited memory and cycles available (The NeXTstation used a 25MHz 68000); their team were not ever going to be able to morph X into an object-oriented platform, which NeXT definitely was; Display Postscript was Adobe's new Hotness; the NeXT folks could write drivers for DP that worked with the Texas Instruments signal processor (TM-9900? I forget), which was truly amazingly fast at screen manipulation; and the X architecture didn't fit well with either Display Postscript or the TM-9900.
In 2001 I had a NeXTstation that I added some memory and a bigger disk to. The machine was by then more than 10 years old. For normal workstation duties, it was faster than my brand new desktop machine due entirely to the display architecture. But compiling almost anything on that 25MHz CPU was an overnight task - I had one compile that ran three days.
Re:oh good (Score:5, Interesting)
Too easy to downmod you.
From your comment about a shitty UI one can only conclude you have never used KDE.
Although better graphics would be nice calling them amateurish is rather silly.
I actually see KDE as the best Linux desktop right now: fast, feature-rich and stable. However I recently watched an interesting criticism piece [youtube.com] regarding some funky and misleading behavior of this desktop environment. The user experience could be improved.
Re:oh good (Score:4, Interesting)
Because Metro sure knocked the socks off of everything...
It points to a new direction; you know one where UI designers cut the tops off their skulls, take an ice cream scooper and remove about two thirds of the brains, put the top of the skull back on.
Metro UI concepts are actually showing up in more and more places. The biggest problem with it was that Microsoft, in their wisdom, tried to force a touchscreen interface on desktop users. The interface itself isn't the problem, the lack of choice for the primary user was...
wayland, systemd (Score:5, Interesting)
Figured systemd would get dragged into this.
One of the biggest problems with systemd is simply documentation. System administrators have a lot of learning invested in SysV and BSD, and systemd changes nearly everything. Changing everything may be okay, may be good, but to do it without explanation is bad no matter how good the changes. I'd like to see some succinct explanation, with data and analysis to back it up. Likely there is such an explanation, and I just don't know about it. But the official systemd site doesn't seem to have much, I'd also like to see a list with common system admin commands on one side, and systemd equivalents on the other, like this one [fedoraproject.org] but with more. For example, to look at the system log, "less /var/log/syslog" might be one way, and in systemd, it is "journalctl". To restart networking it might be "/etc/rc.d/net restart", and in systemd it's "systemctl restart network.service". Or maybe the adapter is wrongly configured, DHCP didn't work or received the wrong info, in which case it may be something like "ifconfig eth0 down" followed by an "up" with corrected IP addresses and gateway info.
When information is not available, it looks suspicious. How can we judge if systemd is ready for production? Is well designed? And that the designers aren't trying to hide problems, aren't letting their egos blind them to problems? To be brusquely told that we shouldn't judge it we should just accept it and indeed ought to stop whining and complaining and be grateful someone is generously spending their free time on this problem, because we haven't invested the time to really learn it ourselves and don't know what we're talking about, doesn't sit well with me.
Same goes for Wayland and MIR. Improving X sounds like a fine idea. But these arguments the different camps are having-- get some solid data, and let's see some resolution. Otherwise, they're just guessing and flinging mud. Makes great copy, but I'd rather see the differences carefully examined and decisions made, not more shouting.
Display server does matter (Score:5, Interesting)
Obviously, display server does matter to users. If users cannot use a whole set of applications because they are not compatable with Distro Xs display server, that is a problem for users. This can be addressed by distros standardizing around display servers that uses the same protocol. Its also possible, but more complex, is if distros using different display protocols support each others display protocols by running a copy of a rootless display server that supports the others display protocol. Relying on widget sets to support all display protocols is too unreliable as we are bound to end up with widget sets which do not support some display protocols. Needless to say, it is best to have a single standard, it would have been easiest and best if Canonical had gone with Wayland and actually worked with Wayland to address whatever needs they had.
Its also true a new display protocol wasnt really necessary. The issue with X was the lack of vertical syncronisation. X already has DRI, Xrender, Xcomposite, MIT SHM, and so on for other purposes. An X extension could have been created to allow a way for an application to get the timing of the display, the milliseconds between refreshes, the time of the next refresh, etc.. X applications could then use this timing information, starting its graphics operations just after the last refresh, X applications could then use an X command to place its finished graphics pixmap for a window into a "current completed buffer" for the window, allowing for double buffering to be used. This could be either a command to provide the memory address, or a shared memory location where the address would be placed. All of the current completed buffers for all windows are then composited in the server to generate the master video buffer for drawing to screen. There is a critical section during which the assembly of the master video buffer would occur, any current completed buffer swap by an application during that time by an application would have to be deferred for the next refresh cycle. A new XSetCompletedBuffer could be created which would provide a pointer to a pixmap, this is somewhat similar to XPutPixmap or setting the background of an X Window, but provided that XPutPixmap might do a memory copy it may not be appropriate, since the point is to provide a pointer to the pixmap that the X server would use in the next screen redraw. Said pixmaps would be used as drawables for opengl operations, traditional X primatives, and such. This scheme would work with all of the existing X drawing methods. the pixmaps are of course transferred using MIT SHM, its also possible to use GLX to do rendering server side, for use of x clients over the network, GLX is preferable, otherwise the entire pixmap for the window would have to be sent over the network. The GLX implementation already allows GL graphics to be rendered into a shared memory pixmap. Currently however, some drivers do not support GL rendering into a pixmap, only a pbuffer, which is not available in client memory at all, however, the DRI/GEM stuff is supposed to fix this and the X server should be updated to support GLX drawing to a pixmap with all such DRI drivers.
Another issue is window position and visibility in how it relates to vertical synchronization. Simplistically the refresh cycle can be broken into an application render period and a master render period. If the X server has a whole pixmap buffer of a window, it grabs at a snapshot of the display window visibility/position state the beginning of the master rendering period and uses that to generate the final master pixmap by copying visible regions of windows into the master buffer.
It can be a good idea to allow the option for applications to only render areas of their windows that are visible, this saves on CPU resources and also avoid needless rasterization of offscreen vector data. In order to do this, applications would need to access visibility data at the beginning of the application render period. Applications would then have to, instead of providing a single