Originally posted by BO$$
View Post
Announcement
Collapse
No announcement yet.
Wayland/Weston 0.95 Land In Ubuntu 12.10
Collapse
X
-
Originally posted by freedam View Postp.s. Please, use Slackware if you don't like changes, I haven't never read of doctors recommending Ubuntu.
Here is the package:
SO, in Slackware, WE have a choice....i bet that in a maximum of 3 (maybe 2) years you won't have a choice in UBUNTU.
As for xWayland , we all know that will be only an interim solution, it will be dropped real fast by Wayland devs...
...and BTW....is LP one of the Wayland devs ?
Comment
-
ugh
I don't understand all the anti-Wayland hate out there. There's some issues that I see (that I'll get to below), but overall it's progress we need. At first, I wasn't sold on wayland, but lets face it, bolting compositing on top of X hasn't worked so well. I boot into windows 7 (less than once a week), and it's clear how much more smooth the compositing is there. Look at the diagrams of how compositing works in X and you'll start to see why things don't run as fast and smooth as they should. I have a core i7 980x, a GTX580, 18GB of memory and an SSD (well, /home is on a 2TB RAID1 array on a 3ware 9750 SATA III controller), and I can't hit anywhere close to a stable 60 fps on my desktop, it's ridiculous. At least my desktop in Linux is snapper, even if it's choppy.
The Wayland architecture should give us a significant and much needed speed boost. It matches up with how modern hardware works, and removes a lot of the unnecessary middlemen inside of the X architecture. I am a bit concerned that some dists may end up trying to push wayland before it's truly ready for prime-time (and/or perhaps before xwayland is also ready). Should this happen, those distributions will end up bleeding users pretty badly and therefore the problem will solve itself.
Here's my problems with wayland:
1. Remoting really isn't being built-in, but will potentially tacked on later. Remoting is awesome, and I think we're throwing out the baby with the bathwater here. Presently, the idea to get remoting in Wayland is to write a compositor that takes the buffers for the windows, and sends them over the network to some remote machine. Not knowing Wayland's architecture too well, will this allow for sharing of individual windows (hacks where the entire desktop is still running on the original machine doesn't count)? The other problem that the the remote machine now must handle drawing the windows instead of the machine with the display. In X, the machine with the display (the server) does the drawing which puts less load on the remote client machine (imagine when a remote machine has to draw for several clients, you can see how this could become a problem). Wayland windows are all drawn via GPU too, correct? This means the remote machine sending the windows over the network would also have to have a GPU powerful enough to handle all of the drawing now.
But maybe this point isn't such a big deal. Correct me if I'm wrong (I'm a big fan of constructive criticism), but my understanding is that the way things are currently done is X is that the toolkits handle all the drawing themselves, not using any of the obsolete X.org drawing commands, then just send/copy all the pixels to the X server (whether the X server is on the local machine or not). This would mean the drawing is already being done on the client machine in X anyway so the Wayland approach to remoting wouldn't really change much here.
2. Are the Wayland devs still locking things to the refresh rate of the monitor? For most people, 60 fps is fine, but there may be cases where this is not sufficient. I know this has been debated on this forum in the past, but there are times when the latency from 60 fps may be too high (especially when you add this to the latency of the monitor). How do I know? I own an arcade where we regularly throw tournaments. We have some professional players come in (and even occasionally some semi-big ones, but I won't drop any names), and latency is a big concern of their's. My business partner and I were aware of the issue before we even opened the business so we've never had any issues, but this has been a problem in some other big tournaments (we're small fries) where they had to replace the monitors during the event (I believe this might've even happened at Evo once years ago). In fighting games, timing is everything. In FPS games, accuracy is everything. Latency at this level may not be an issue for us mere mortals, but it comes to the tournament players, this matters.
Then there's the issue of when the framerate can't keep up with the refresh rate... What if the framerate dips to 59? Well, you're not going to see 59 fps, it's going to drop to something like 30 or 45 fps to sync up with the monitor which can jarring and ugly (but is at least still tear-free). For the desktop in general, this tradeoff is clearly worth it. But for a game, having the ability to enable or disable vsync is pretty important. Hopefully applications will be able to support enabling and disabling vsync on an individualistic basis at least eventually.
Comment
-
Originally posted by AJSB View PostWhat are you mumbling about ? *IF* i wanted PulseAudio, as an example, i also can have it in Slackware.
Here is the package:
SO, in Slackware, WE have a choice....i bet that in a maximum of 3 (maybe 2) years you won't have a choice in UBUNTU.
As for xWayland , we all know that will be only an interim solution, it will be dropped real fast by Wayland devs...
...and BTW....is LP one of the Wayland devs ?
Comment
-
Originally posted by AJSB View PostAs for xWayland , we all know that will be only an interim solution, it will be dropped real fast by Wayland devs...
Originally posted by AJSB View PostWhat are you mumbling about ? *IF* i wanted PulseAudio, as an example, i also can have it in Slackware.
Comment
-
Originally posted by Teho View Post...and if you don't want to use PulseAudio on Ubuntu or on any other distribution for that matter you don't have to either. It's just that Ubuntu packages Gnome and other software that have hard dependecy on it. You actually have a lot more choise on Ubuntu because it provides more software than Slackware.
Aaaaahhhh, *there* is the problem ....i removed Pulse Audio from UBUNTU and almost everything was working OK....then i tested WET and JIN and there was no way to get audio playing from them....i found more with same problem...is much better to not have it in a base installation and add it if you really want than the other way around.
....and it's not only UBUNTU that hardwires apps to PA....other distros do the same....and this is a big problem....it shouldn't be hardwired AT ALL....
As for UBUNTU have or not more software than Slackware, i'm not that sure of that....at least i never had a problem to get what i wanted/needed for Slackware.
Comment
-
Originally posted by hiryu View PostPresently, the idea to get remoting in Wayland is to write a compositor that takes the buffers for the windows, and sends them over the network to some remote machine. Not knowing Wayland's architecture too well, will this allow for sharing of individual windows (hacks where the entire desktop is still running on the original machine doesn't count)?
The other problem that the the remote machine now must handle drawing the windows instead of the machine with the display. In X, the machine with the display (the server) does the drawing which puts less load on the remote client machine (imagine when a remote machine has to draw for several clients, you can see how this could become a problem). Wayland windows are all drawn via GPU too, correct? This means the remote machine sending the windows over the network would also have to have a GPU powerful enough to handle all of the drawing now.
Are the Wayland devs still locking things to the refresh rate of the monitor? For most people, 60 fps is fine, but there may be cases where this is not sufficient. I know this has been debated on this forum in the past, but there are times when the latency from 60 fps may be too high (especially when you add this to the latency of the monitor). How do I know? I own an arcade where we regularly throw tournaments. We have some professional players come in (and even occasionally some semi-big ones, but I won't drop any names), and latency is a big concern of their's.
"Professional gamers" (ugh) usually imagine the latency problem; they're interested in getting any possible edge, real or not, and are all too ready to blame anything and anyone except themselves when they don't play perfectly ("I don't suck, this computer just had vsync turned on, this is bullcrap!"). You get a lot of that in any competitive sport; people who believe in lucky socks, crap like that. There's feedback bias going into it. The monitor is physically incapable of displaying faster than its refresh rate, with or without vsync. That's not to say that it wouldn't better to have higher refresh rates than the relatively low 60hz that has become standard (120hz being the golden number, as it is slightly higher than what a human can perceive and has numerical properties that make it ideal for compatibility with legacy tech), but unless the monitor supports 120hz there is zero reason to actually render at 120hz. Note also that many games are just coded improperly and suffer additional lag in the whole system with vsync on; this is not the fault of vsync or the display system in general, but rather the game engines blocking everything until a vsync event instead of merely delaying rendering (triple buffering is the easy way to fix this for games that work that way, if your driver allows you to force it on).
Then there's the issue of when the framerate can't keep up with the refresh rate... What if the framerate dips to 59? Well, you're not going to see 59 fps, it's going to drop to something like 30 or 45 fps to sync up with the monitor which can jarring and ugly (but is at least still tear-free).
That said, adaptive vsync is a thing (sync to 60 fps if it can handle it, and disable vsync if it can't), and it would be very easy to make a Wayland do that if it turns out to be a problem. I imagine that full-screen apps could be allowed to directly set the scanout buffer as well. As is, there is only a single extra context switch required when flipping buffers, but if Wayland has a command (or possibly it can be all automated by the server with no protocol changes at all!) to map a fullscreen window to that display's scanout buffer, the app/game would be in full control of when buffers are swapped.
Comment
-
Originally posted by AJSB View Postis much better to not have it in a base installation and add it if you really want than the other way around.
Originally posted by AJSB View Post....and it's not only UBUNTU that hardwires apps to PA....other distros do the same....and this is a big problem....it shouldn't be hardwired AT ALL....
Originally posted by AJSB View PostAs for UBUNTU have or not more software than Slackware, i'm not that sure of that....at least i never had a problem to get what i wanted/needed for Slackware.
Comment
-
Originally posted by Teho View PostUbuntu is distribution for non-technical people. It's important that stuff like bluetooth and multi-channel audio work properly out of the box. It's the minority that has any problems with PulseAudio so not taking advantage of these features would be plain stupid.
Ubuntu doesn't "hardwire" anything. It's the application developers who choose to do so. PulseAudio is the de facto audio server on Linux so it's no wonder why application developers might not want to waste their time supporting other audio systems for no added gain (libpulse works fine with ALSA even without PA server).
Debian has more packages than anyother distribution aside from its derivatives like Ubuntu and Mint that have even more. Slackware for one doesn't even package Gnome.
Bur even talking about PA, UBUNTU and others should give a TRUE AND SIMPLE WAY TO DISABLE IT if we want (that actually is funny taking in account what you say about UBUNTU is for the non-techie and reading all the posts in UBUNTU forums about how in the hell to disable PA and then audio not working in some apps or even worse, how to get rid of Nouveau and how to install a freaking PROPER VIDEO DRIVER with performance with same level of the one for Windows instead of that thing called Nouveau.
You say that is not UBUNTU fault that apps devs hardwire for PA....excuse me ?!? aren't those apps FOSS ?!? aren't many of those same apps also shipped with or for Slackware w/o PA ?!? So, what's so hard to UBUNTU make a kind of "if PA present use PA else use ALSA" in the code ?!?
That would make everyone happy.....but NOOOO that have to shove it down and make damn sure that it's darn difficult to remove it w/o screwing things up...
As for GNOME, taking in account that i can use GTK+ apps in Slackware, i don't really care or miss it.Last edited by AJSB; 26 August 2012, 06:05 PM.
Comment
Comment