Originally posted by frank007
View Post
Announcement
Collapse
No announcement yet.
X.Org vs. Wayland Browser Performance With Firefox + Chrome
Collapse
X
-
-
Originally posted by frank007 View PostIt's not true. Post where we can read this or stop throlling...
There are some releases due to migration to gitlab and some smaller fixes, but there is no real progress anymore. Also do your research on xserver 1.21., it's just not happening since a long time. Maybe check the activity here and try to spot something not related to Wayland or being simple compile fixes in 2020:
That's the exact definition of dead.
- Likes 1
Comment
-
For me, wayland is practically unusable. Once it's usable, I will switch over to it.
Is it the solution in need for a problem? Probably it is, I don't know, nor do I care since X works just fine. As for security..., it's clearly secure enough = proven over time already. As for real world performance, wayland is nowhere near X, and it likely will never be. It's the same type of argument Windows users use with every new version of Windows:
Windows 10 is faster than Windows 8.1, Windows 8.1 is faster than Winsows 7, Windows 7 is faster than Windos Vista, Vista > XP and so on...
It was never valid argument, and never will be, every next Windows OS was slower than previous one, always, as long as you are using objective measure of performance.
Another extremely dumb argument is 'features vs performance', also inherited from Windows OS version debate..., Argument goes: 'It is slower, but it have X feature you know...', well, who cares? Any feature can be made to be executed only WHEN it's needed, so that argument can't stand as valid.
Another ridiculous argument is security..., more complex systems are by default less secure, you can't avoid that, simply because the more things you do, the more likely you will make mistake and less likely you (or anyone else) will recognize that mistake.
Design choices are different beast altogether, is it better to have one piece of software doing one thing and one thing only well, or group such things into modular or non-modular application? There are valid arguments for each case...
Anyway, wyaland still sucks for most people, that's the truth, if you don't like it, well..., what can we do about it, if it doesn't suck for you, great, much better, you may contribute to faster development and usability and rest of us will migrate to it faster when it become usable .
- Likes 1
Comment
-
Originally posted by frank007 View PostIt's not true. Post where we can read this or stop throlling...
- Likes 1
Comment
-
Originally posted by leipero View PostFor me, wayland is practically unusable. Once it's usable, I will switch over to it.
Is it the solution in need for a problem? Probably it is, I don't know, nor do I care since X works just fine. As for security..., it's clearly secure enough = proven over time already. As for real world performance, wayland is nowhere near X, and it likely will never be. It's the same type of argument Windows users use with every new version of Windows:
Windows 10 is faster than Windows 8.1, Windows 8.1 is faster than Winsows 7, Windows 7 is faster than Windos Vista, Vista > XP and so on...
It was never valid argument, and never will be, every next Windows OS was slower than previous one, always, as long as you are using objective measure of performance.
Another extremely dumb argument is 'features vs performance', also inherited from Windows OS version debate..., Argument goes: 'It is slower, but it have X feature you know...', well, who cares? Any feature can be made to be executed only WHEN it's needed, so that argument can't stand as valid.
Another ridiculous argument is security..., more complex systems are by default less secure, you can't avoid that, simply because the more things you do, the more likely you will make mistake and less likely you (or anyone else) will recognize that mistake.
Design choices are different beast altogether, is it better to have one piece of software doing one thing and one thing only well, or group such things into modular or non-modular application? There are valid arguments for each case...
Anyway, wyaland still sucks for most people, that's the truth, if you don't like it, well..., what can we do about it, if it doesn't suck for you, great, much better, you may contribute to faster development and usability and rest of us will migrate to it faster when it become usable .
Regarding your point about performance: it's a common misconception that wayland is slower than X and it comes from two confusions. Technically it is almost impossible for Wayland to be slower than Xorg because it uses the same rendering engine, the same drivers and the same code paths as modern composited X sessions, without the unused X server in the way and the associated context switches from the app to X to the compositor to the window manager and back. When people complain about Wayland being slower they in fact almost always mean X11 apps running on top of Wayland through XWayland, not native Wayland apps. There is little fundamental reason why XWayland should be slower than native X but in practice it seems to be the case, even though as recent benchmarks published by Michael show, the difference is often not noticeable. If you run native Wayland software (GTK3-based etc.) it's already faster than X11 today, and it literally flies: Nautilus windows finally resize smoothly and without lag or artefacts, the desktop reactivity is FINALLY on par with Windows 10 on the same machine, etc.
The second reason is that in a Wayland session, the compositor handles more tasks than under a composited X session and it is really performance critical. A poorly implemented compositor will have a much bigger performance impact on Wayland than on X11. It's a reality that virtually all compositors that people actually use (not talking about Weston...) are ports from X11 compositors. Only Gnome Shell 3.36 comes close to being what a native Wayland compositor should be; it's not quite there yet, but it's getting close. In other words implementing a good Wayland compositor is much more performance critical than on X11 and it's much more challenging than writing a X11 window manager. We can expect that with Wayland, the tradition of people writing various little window managers (like we had fvwm, afterstep, i3 etc...) will probably vanish; there will be Gnome, KDE and perhaps Sway.
If you say that X11 security has been proven through time, I disagree. It has been proved to require many various kludges and band-aid fixes to remain acceptable, and if disaster never stroke it's in no small part thanks to the fact that malware (especially desktop malware) is much less common on Linux than on Windows. The fact remain that even today there is absolutely nothing to stop a program from invisibly recording your entire desktop session and streaming it out, and you would probably never notice.
The reality is that Wayland will never reach exact feature parity with X11 because by design it's not meant to. There will never be a version of sxhkd or "ssh -X" for Wayland, which doesn't mean that there will be no support for hotkeys (but it will have to be implemented as a compositor add-on, not as a user daemon) or that there will be no remote administration - that will have to be done using a combination of RDP and Web applications. If you expect a Wayland powered Linux to be the same thing as X11-linux with the same use cases and the same kinds of applications, then you WILL find Wayland inferior. But that's absolutely not the point.
- Likes 2
Comment
-
Originally posted by TemplarGR View Post
So, you are hating Wayland because you want to use XFCE with it and it doesn't run under Wayland? So you come up with various pretenses to claim Wayland isn't ready? LOL you sound bitter.
By the way, why XFCE is "the only sane desktop environment"? Define "sane" please....Last edited by birdie; 11 April 2020, 06:46 PM.
Comment
-
Originally posted by jacob View Post
This is a decade-old list of half truths, FUD, obsolete issues solved long ago and very occasionally sensible points. Wayland applications don't need to implement "their own font anti-aliasing". They use Freetype, which is, among other things, the same engine as on iOS, and of course it has a system-wide settings API. Re DPI settings, it is of course up to toolkits (not applications) because by design, Wayland is all-client-side. Unless you want to do rendering in the server (and there are extremely important reasons why you shouldn't) then it has to be handled on the app side, that is by the toolkit. DPI is of course set system-wide but the rendering adjustments need to be done at the toolkit level. Once again, that's how it's done on both Windows and Mac. From the plethora of half-assed toolkits from the X11 era there are essentially only two left, GTK and Qt, and both ALREADY support DPI scaling so that point is definitely moot. By the way Qt's future as a FOSS-relevant framework is currently in doubt due to the uncertainty regarding its future licensing, so potentially there may really be only one toolkit to worry about. Regarding the game-related issues, I played a couple of games recently and didn't experience any of the so-called problems described there. And so on. Let me know when an actual problem caused by Wayland really arises (NB: "that's not how it was done in X" or "it doesn't work on Xenix 1.0" don't count as problems).
Comment
Comment