Lower ram usage doesn't always mean lower cpu / gpu usage. Also, I wonder how much is loaded in VRAM for each case.
Even if a lot of the memory use is in VRAM, it's an improvement. It means you have more RAM available for apps, instead of graphic buffers, and that those are where they should be processed (which means they will be processed faster, because you don't need to wait for the bus). Also, this memory use will not be probably from Wayland, but from the apps, which is not really relevant when comparing Wayland to X.org. Of course, if X.org does it the inefficient way, it will show as consuming more than it's actually relevant.
Originally Posted by ethana2
I've contacted the Maui Project about the lack of 32 bit builds for their LiveCD, and they say as long as they have to use QT5 git, offering a 32 bit version would be rather labor intensive. I'm hoping that several months down the line perhaps, if they can use a regular Qt5 release, maybe we could get a 32 bit version to take advantage of the decreased memory footprint on older machines..
It's not that hard to build for different architectures. Just make two different build directories and build for one target on each. IIRC (I'm more comfortable with CMake, since I just make some toolchains to adapt it to whatever I want) it's just running, from the build dir, ../configure --target=i686-gnu-linux or something like that. From that point, you pull, you make, you are happy.
Originally Posted by Ancurio
Yes, good point. I don't know the details, but I think Xorg still stores all its pixmaps in normal RAM (correct me if I'm wrong?). With Weston and the DRM backend,
those drawing buffers would all exist directly in VRAM, which would inflate the visible numbers quite a bit. Too bad there's no standard way to measure VRAM usage..
(aside from some vague GL extensions maybe)
If that's the case, it's an improvement already, at least for desktops.