Announcement

Collapse
No announcement yet.

The Wayland Situation: Facts About X vs. Wayland

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • garegin
    replied
    Originally posted by elanthis View Post
    Sort of, yeah. Applications run in different "profiles" which alters how things work in various ways. It's similar to the kernel personalities in BSD and the like which allow for Linux binaries to run unaltered, but it extends down to the library level as well, similar vaguely to how glibc adds extra mangling to some symbol names so that old binaries using "fstat" or the like get a result laid for 32-bit size values but all newer binaries compiled against newer headers get 64-bit-friendly layouts. Essentially apps run in a "container" of sorts that acts more like an older edition of the OS from top to bottom.

    What Linux can learn from this, I don't know. The Windows solution is horrible in a lot of ways (other than that It Works). Trying to wrap your head around WoW64 or the like is just a pain compared to the common Linux bi-arch or multi-arch setup, and XWayland is a much cleaner and easier concept to grok than "compatibility mode." The Linux way has its own annoyances, but excels in some areas. Whether or not some hybrid approach is even better we may well never know.

    I'm unsure how OSX deals with such things. I think it's closer to Linux, though.
    what I effing hate is that modern applications don't just serve you 64 bit, when possible, even though many people use it. in many cases, one has to specically choose the 64 bit version. At least Apple more aggressive in offering 64 bit, even though you can still run 32 bit apps in 10.9

    Leave a comment:


  • Darxus
    replied
    Please keep the posts more constructive than ad hominem attacks. I just deleted several posts from Paradox Uncreated and a couple replies quoting him. (Thanks for using the "!" report links.)

    Leave a comment:


  • dee.
    replied
    Talk about wayland or GTFO.

    Leave a comment:


  • Vim_User
    replied
    Originally posted by Paradox Uncreated
    Looking forward to jitter free desktop recording It really is awful that there is so much jitter/little timing accuary when doing simple things like desktop record.

    http://www.youtube.com/watch?v=35ogJmzg4jg

    Automatic screenhz change to video, etc would be great too.

    Peace.
    Are you only here to advertize your kernel, for which you think it is an achievement to play a 10 years old game on a five yoears old machine?

    Leave a comment:


  • daniels
    replied
    Originally posted by bwat47 View Post
    according to the comment you linked, server-side *only* had performance/power benefits on certain ARM chips, on x86 client-side is preferred, so it makes sense that wayland would be agnostic since neither one is 100% superior in every scenario.
    ^ yes, this. (10)

    Leave a comment:


  • quasipedia
    replied
    Originally posted by bwat47 View Post
    according to the comment you linked, server-side *only* had performance/power benefits on certain ARM chips, on x86 client-side is preferred, so it makes sense that wayland would be agnostic since neither one is 100% superior in every scenario.
    Hej, thanks, this answers the second question. Any idea why allocating by server (on the chips) is more energy efficient than allocating by clients? And also (new question!) why on x86 client side is preferred (still power management reasons, or...)?

    Thanks!

    Leave a comment:


  • bwat47
    replied
    Originally posted by quasipedia View Post
    I found here a comment by daniels mentioning the server-side vs. client-side querelle between wayland and mir. Later in the thread it is said that the difference between the two has considerable implications in terms of energy consumption.

    Is there anybody that could explain why is so, and what is the rationale behing wayland choosing to be agnostic?

    Thanks!
    according to the comment you linked, server-side *only* had performance/power benefits on certain ARM chips, on x86 client-side is preferred, so it makes sense that wayland would be agnostic since neither one is 100% superior in every scenario.

    Leave a comment:


  • Sonadow
    replied
    Originally posted by gamerk2 View Post
    Eh, WOW64 isn't the cleanest solution on the planet, but it does get the job done nearly 100% of the time, with very little (if any) measurable performance hit. Still, when you have over a decade of closed-source, 32-bit applications that people still use, its a necessary evil. Obviously, a recompile is best, but most would rather just maintain the 32-bit .exe rather then have to build/debug two separate builds.
    Originally posted by elanthis

    I'm unsure how OSX deals with such things. I think it's closer to Linux, though.
    It's very different (or was).

    Last I remembered back in OS X 10.6 they grafted 64bit userland over a 32bit PAE kernel even though the operating system installs both the 32bit and 64bit kernels.

    The 64bit kernel was essentially disabled and completely hidden from view so that it would never be invoked by an end user; the only way to boot into the full 64bit environment (64bit userland and 64bit kernel) was to reboot the machine and hold down the '6' and '4' keys during the boot sequence.

    Not sure how it works in the newer versions of OS X.

    Leave a comment:


  • gamerk2
    replied
    Originally posted by elanthis View Post
    Sort of, yeah. Applications run in different "profiles" which alters how things work in various ways. It's similar to the kernel personalities in BSD and the like which allow for Linux binaries to run unaltered, but it extends down to the library level as well, similar vaguely to how glibc adds extra mangling to some symbol names so that old binaries using "fstat" or the like get a result laid for 32-bit size values but all newer binaries compiled against newer headers get 64-bit-friendly layouts. Essentially apps run in a "container" of sorts that acts more like an older edition of the OS from top to bottom.

    What Linux can learn from this, I don't know. The Windows solution is horrible in a lot of ways (other than that It Works). Trying to wrap your head around WoW64 or the like is just a pain compared to the common Linux bi-arch or multi-arch setup, and XWayland is a much cleaner and easier concept to grok than "compatibility mode." The Linux way has its own annoyances, but excels in some areas. Whether or not some hybrid approach is even better we may well never know.

    I'm unsure how OSX deals with such things. I think it's closer to Linux, though.
    Eh, WOW64 isn't the cleanest solution on the planet, but it does get the job done nearly 100% of the time, with very little (if any) measurable performance hit. Still, when you have over a decade of closed-source, 32-bit applications that people still use, its a necessary evil. Obviously, a recompile is best, but most would rather just maintain the 32-bit .exe rather then have to build/debug two separate builds.

    Leave a comment:


  • JS987
    replied
    Originally posted by brosis View Post
    Thanks for posting this; although as noted - raster and glamor/gl are tested on non-wayland. I have, kind of, no objections that raster is slower on X. But since we talk about wayland/raster vs X/(whatever is fastest, preferably SNA), seeing that tested that would be nice.
    I think software rasteriser isn't accelerated by GPU which means even if it will be fast as SNA it will hog CPU much more.

    Leave a comment:

Working...
X